More on the SYSOP SECURITY emergency!!!!

    Date:  01-01-89.

    From Kevin Dahlstedt sysop for
         Rabbit Mountain BBS
         (303) 460 1093
         300-9600 bps  HST

    In an earlier document (SYSOP.TXT) Richard  Johnson  hits  upon  a
    very  dangerous  problem inherent with the way WILDCAT BBS systems
    accept uploads.  In summary, Richard basically says that  external
    uploads  of  files  can  overwrite  existing  batch  files or .com
    files.  This occurs when your  external  upload  system  initially
    uploads  files  into  the  same  directory that contains the batch
    files and/or program files.

    This problem is not however, limited to known uploads  like  those
    outlined  by  Richard.   The  problem  is  much  more  complex and
    potentially dangerous.  The  scenario  described  by  Richard  can
    occur a number of ways.

    First,  a caller can select the upload option, type in a name such
    as  DSZ.COM  or  ZUP.BAT,  start the upload, and WHAM.....security
    problem!  This scenario is described in more  detail  in  Richards
    document.

    Second, a caller can select a download for some  specific  program
    that  you  just  MIGHT  have  in  your  collection  for  available
    downloads that just HAPPENS to  match  a  file  in  your  protocol
    directory  (like  DSZ.COM) and if this same caller selects the use
    of  some  external  protocol  then  once  again   WHAM....security
    breech!   This occurs because WILDCAT copies the needed files into
    the protocol directory before passing the necessary parameters  to
    the protocol's batch file.  Once the external protocol is finished
    WILDCAT  deletes the files that were just copied.  This problem is
    less dangerous than the once mentioned previously since  the  file
    is just deleted and not replaced, however the next scenerio is one
    that  should  scare  the  HELL  out  of  you, if you sysop WILDCAT
    boards!!

    Third, and the most dangerous of these scenarios, involves the use
    of external protocols that allow  batch  transfers.   Imagine  our
    caller  selecting  the upload option and providing a innocent name
    like GAMENAME.ARC, BUT on the callers side of  things  the  caller
    actually  sets his version of DSZ (or other batch protocol driver)
    to send BOTH GAMENAME.ARC AND ZDOWN.BAT.  All statistics  for  the
    upload  will  actually  show  the upload working correctly and the
    file being copied to the  correct  directory  and  NO  information
    pointing  to  the EXTRA upload that has been sent.  NO way to know
    that it is there...NO way to know WHO sent  it!   If  that  second
    upload contains the right information you can kiss the information
    on your disk drives GOODBYE and have NO way to catch the culprit.


    So....are you scared enough yet......well here are some solutions:

    First, and   BEST,   do  what  Richard  Johnson  suggests  in  his
    document.   Make  all  the  files  in  your   protocol   directory
    READ-ONLY.

    Second,  set all external protocols to  upload  into  a  temporary
    directory  instead  of  the  protocol  directory.   By  doing this
    individuals that do send you files that HAPPEN to  have  the  same
    name as protocol files will not be stopped from doing so.  Thus if
    some  nice guy like Richard decides to send you the latest copy of
    JMODEM.COM and forgets to make it an ARC file the upload  will  be
    accepted  and  be  in a usable format.  Also if some BAD GUY sends
    you EXTRA files with a batch upload they will end up in  the  temp
    directory  which  should  ALWAYS be empty (thus it will be easy to
    detect that something wrong has happened).

    Third,  make up an fake file area that ONLY the sysop  has  access
    to, and  put  a  copy  of  all PROTOCOL files into that file area.
    Then 'add' them into your files database  so  that  any  attempted
    uploads will be 'denied' due to inability to overwrite!

    Fourth, verify that you  do  not  have  ANY  files  available  for
    download  that  can  accidently overlay one of your protocol files
    and thereby result in eventual deletion of that file  or  download
    of the wrong file.

    Fifth, use  Richard  Johnsons  LOG  program  to monitor the actual
    performance of the upload.  This can be done like this:

      DSZ port %2 speed %1 rz %3 %4 %5 %6 %7 %8 %9 | LOG Zmodem UPLOAD

        Note: This instruction results in the  saving  of  the  actual
              text output from DSZ in a log file that is both date and
              time  stamped!!!   If you ever find a mysterious file in
              your temp UPLOAD directory you can track it back to  the
              PERSON  who  attempted the BREAK....CATCH that vandal in
              his tracks.......heh heh heh.



    I discovered  these  problems  by  doing  some  test  uploads  and
    downloads  that resulted in some very bizarre problems.  Avoid the
    problems altogether and protect yourselves!

    To any other sysops reading this.......Happy 1989!

    Kevin