CP/M/CPM_CDROM.iso/cpm/rcpm/secursys.doc

Text File | 1994-07-13 | 9.4 KB | 164 lines

SECURSYS.DOC as of 7/10/81

     Doesn't  it  really burn you when some jerk logs  into  your
remote  CP/M  system (that  you've spent hundreds  of  hours  and
thousands  of dollars to put on-line for public use) and promptly
tries to steal you blind and crash or ruin your system?   In  the
(almost)  2  years  that Technical CBBS has been  on  line,  I've
compiled  a user log about 6 feet high (no kidding,  5  boxes  of
3000 sheets each) that probably has at least one example of every
possible  thing that a system crasher can try to steal or  screw-
up.  I've been keeping a list of the "top-10" solutions that I've
found  since TCBBS has been in operation,  which might be of some
use to new SYSOP's.  There is nothing amazing in the  file,  it's
mostly  just  common sense,  but it is very easy to forget  these
ideas.  I know that from many painful experiences.
     SYSOP'S, here are some things you can do to stop a potential
system crasher:

1.      Keep a CRCK file for ALL of the .COM files that you leave
    on-line  (And also any other files that get loaded  into  the
    TPA  and  executed,  like MINICBBS.OBJ).   If  you  have  any
    password files (like the PWDS file used by RBBS),  CRCK those
    too.  For obvious reasons, don't leave the CRCK file on-line.
    (CRCK.ASM  is  a program that produces  a  cyclic-redundancy-
    check value for any specified files.)

2.      Use  MDIR.COM frequently to see what goodies the jerk may
    have left you in certain user  areas.   Note;  however,  that
    MDIR.COM  will NOT find files that are "hidden" in the  "user
    areas" above 20H!  The best way to see everything on the disk
    is  to  use  the MAP (M) function of DU.COM.   It  will  show
    EVERYTHING on the disk, even the remains of any erased files.
    I  routinely Map the disks on TCBBS and SYSOP CBBS and  have,
    on occasion, found special files and other no-no's on both.

3.      Don't  leave any .COM files on the system that can  allow
    a remote user to find .SYS files.   Most directory  programs,
    and  also  WHATSNEW allow anybody to list .SYS files by  just
    typing  an extra character or two.   The best thing to do  is
    remove the .SYS list options altogether.   (A quick fix is to
    DDT  the  .COM  file and change the character  to  a  control
    character  like  ^C which can't be entered into  the  command
    buffer.)

4.      Keep  a hard-copy log of all remote input to the  system.
    Although  a log won't actually make your system more  secure,
    it will give you an opportunity to see how anybody "gets in",
    and will,  hopefully, insure that the same break-in procedure
    can't be used twice.   Installing a log is really easier than
    it sounds, since it only requires printing the stuff typed by
    the  remote  user,  not the stuff typed by  the  system.   An
    inexpensive (i.e.  cheap) printer is perfect, since you don't
    need  letter-quality type to see who's been screwing up  your
    $3000-and-up  computer  system.    Many  BYE  programs  (like
    BYE69.ASM) already include the option for a hard-copy log.

5.      Of  course,  you  should also change the  CP/M  commands.
    Again,  the  best  thing is to REMOVE commands like  ERA  and
    SAVE,  but if you're not that ambitious,  or if you think you
    can't do without them, just change them as usual, with SYSGEN
    and DDT.  Try to pick new commands that aren't easy to guess,
    although  it's  impossible to guarantee that no one  will  be
    able to figure them out in time. (I have a listing from TCBBS
    log  where some idiot spent about 8 hours trying to find  one
    of  the commands.)  If you want to eliminate a  command,  you
    can  embed a control character into the command word and make
    it impossible to use.

6.      Don't leave any .COM files out that would allow a  remote
    user to examine or modify memory, or to load a .HEX file.  It
    is perfectly safe to leave out ASM.COM, because it can't make
    a  .COM  file,  but to leave LOAD.COM or L80.COM  out  is  to
    invite a remote user to download his favorite debugger to see
    what  he  can do.   BASIC.COM and DDT.COM are also bad  news,
    since  both  could  allow a remote user to  make  changes  in
    memory.   Even a compiler can be left safely on-line, as long
    as  its associated loader program is  not  available.   Also,
    don't  leave out any files that would allow a remote user  to
    send a .COM file over to your system.   XMODEM.COM checks for
    .COM  files  and won't allow them,  but many other  programs,
    like MODEM.COM and BSTAM,  will allow ANY file to be sent  or
    received.  Once a system crasher has a way to download a .COM
    file to your system, all is lost.

7.      In  CP/M 2.x,  an illegal drive request might also change
    the current user area!   In other words,  a remote caller who
    is  logged  into A:  user 0 could type "Q:" and end up on  A:
    user  1!  Digital  Research doesn't think of this as  a  bug,
    because  in an unmodified CP/M system,  a disk  select  error
    will  cause a PERMANENT BDOS error.   The problem arises when
    the  user  changes his BIOS to allow a warm-boot  on  a  disk
    select  error,  instead  of  a permanent  BDOS  error.   CP/M
    doesn't  reset  the user/drive  byte  properly.   That's  the
    reason for the strange results.  This problem can be fixed in
    your  BIOS  by properly handling a SELDSK error,  but if  you
    don't have the source for your BIOS, you could be in trouble.
    Another  way to protect yourself against this problem  is  to
    keep  "private" stuff in user 5 or 16-32.   Strangely enough,
    all  other  user areas can be entered with an  illegal  drive
    code.   Putting things in user 5 will make them pretty  safe,
    and,  of course, putting things in user areas 16-32 will make
    them even safer,  but the CCP can't get YOU into those areas,
    so  their use is a bit restricted.   Most BYE programs have a
    MAXUSER  equate that will keep remote users out of  any  area
    greater than a preset value,  so they can also protect you to
    a certain extent from an illegal drive select.

8.      You  can protect licensed or private software by  keeping
    it  in  an unaccessible user area,  and using a short  loader
    program  like  Keith Petersen's  SECURITY.ASM.   This  really
    works,  and makes the SYSOP feel good when he sees in the LOG
    that  some  BOZO who thinks he has just  successfully  stolen
    MINICBBS has actually just stolen a short loader program.

9.      Probably  the  biggest  security  problem  is  INCREDIBLE
    STUPIDITY.   It is rumored that some SYSOP's have  actually
    done  really dumb things like leave PIP.COM or  MODEM.COM  or
    FORMAT.COM  (shiver...) out in a public user  area!   If  you
    absolutely  have  to leave one of these  (potentially)  nasty
    little  programs on your system,  put it in a user area  that
    can't  be  accessed remotely (or at least a non-public  area)
    and rename it to a .OBJ file.  Then even if someone gets into
    the user area with the program, he can't run it (.OBJ).

10.     Don't leave your system or CP/M passwords anywhere on the
    system.   Use  TAG.COM to make sure that someone can't XMODEM
    your BYE.COM program and other goodies.  Don't leave a SYSGEN
    image  (CPM56.COM) laying around either,  since it  could  be
    downloaded  and  DDT'ed to find the system  commands.   Also,
    don't  leave your system PW's on another system in a  private
    message  to  a  friend thinking that his  message  system  is
    private,  because it probably isn't.  I'm not being paranoid,
    everybody REALLY IS trying to break into my system...

Some  of these things may seem like a pain in the neck,  but  the
more  prevention you do,  the less you have to worry about the  1
jerk in a thousand callers who wants to mis-use your system.   NO
SYSTEM  is  absolutely  secure,  but with these  suggestions  you
should be able to run a system that is almost absolutely  secure,
which isn't really that bad.

   Good luck,  Dave Hardy   Sysop, TECHNICAL CBBS [phone]
                            Sysop, SYSOP CBBS [phone]

P.S.  Please pass any additions or corrections on to me at one of
the above systems.  -thanks

COROLLARIES:

11.     Watch out for booby-trapped .COM files!  If someone sends
    down  an  .OBJ file suggesting that you leave it out on  your
    system,  be sure to check that file for any hidden  functions
    that may allow someone to break into your system later.   One
    way  to  prevent this would be to only leave out  .COM  files
    that you have assembled from SOURCE files.   In any case,  be
    suspicious  of  any files left you for public use that  don't
    have  the source with them.   A good programmer could hide  a
    secret function in a .COM file so well that it could only  be
    found  with  a great deal of  difficulty.   In  addition,  an
    unknown  .COM file might also have many other terrible hidden
    functions  (See  BANZAI.ASM for some ideas) that  could  even
    destroy other files on the system's disks, so be careful.
                         -Dave Hardy (as suggested by Ron Fowler)