106 lines
5.1 KiB
Plaintext
106 lines
5.1 KiB
Plaintext
|
||
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
|
||
|
||
|