Archive-name: security-faq
Last-modified: 1993/12/3
Version: 2.2
Version History:
2.2 LD_PRELOAD comment
2.1 New story, TAMU package info
2.0 MERGE IN LOTS OF NEW INFORMATION
1.6 Minor revisions, meant to bring it a bit more up to date.
1.5 Structural revision.
1.4 Fixed John Haugh's name, modified entry for "shadow"
Added Ulf Kieber's update on the rainbow series
Added bit about Karila paper
1.3: Tweak for comp.security.misc/news.answers
Updated entry for orange book (foreign purchases)
1.2: Undocumented prior to this
---------------------------------------------------------------------------
Almost Everything You Ever Wanted To Know About Security*
*(but were afraid to ask!)
This document is meant to answer some of the questions which regularly
appear in the Usenet newsgroups "comp.security.misc", "comp.security.unix",
and "alt.security", and is meant to provide some background to the
subject for newcomers to that newsgroup.
This FAQ is maintained by Alec Muffett (Alec.Muffett@UK.Sun.COM), with
contributions from numerous others; the views expressed in the document
are the personal views of the author(s), and it should not be inferred
that they are necessarily shared by anyone with whom the author(s) are
now, or ever may be, associated.
Many thanks go to (in no particular order): Steve Bellovin, Matt Bishop,
Mark Brader, Ed DeHart, Dave Hayes, Jeffrey Hutzelman, William LeFebvre,
Wes Morgan, Rob Quinn, Chip Rosenthal, Wietse Venema, Gene Spafford,
John Wack and Randall Atkinson.
Disclaimer: Every attempt is made to ensure that the information
contained in this FAQ is up to date and accurate, but no responsibility
will be accepted for actions resulting from information gained herein.
Questions which this document addresses:
Q.1 What are alt.security and comp.security.misc for?
Q.2 Whats the difference between a hacker and a cracker?
Q.3 What is "security through obscurity"
Q.4 What makes a system insecure?
Q.5 What tools are there to aid security?
Q.6 Where can I get these tools?
Q.7 Isn't it dangerous to give cracking tools to everyone?
Q.8 Why and how do systems get broken into?
Q.9 Who can I contact if I get broken into?
Q.10 What is a firewall?
Q.11 Why shouldn't I use setuid shell scripts?
Q.12 Why shouldn't I leave "root" permanently logged on the console?
Q.13 Why shouldn't I create Unix accounts with null passwords?
Q.14 What security holes are associated with X-windows (and other WMs)?
Q.15 What security holes are associated with NFS?
Q.16 How can I generate safe passwords?
Q.17 Why are passwords so important?
Q.18 How many possible passwords are there?
Q.19 Where can I get more information?
Q.20 How silly can people get?
---------------------------------------------------------------------------
Q.1 What are alt.security and comp.security.misc for?
Comp.security.misc is a forum for the discussion of computer security,
especially those relating to Unix (and Unix like) operating systems.
Alt.security used to be the main newsgroup covering this topic, as well
as other issues such as car locks and alarm systems, but with the
creation of comp.security.misc, this may change.
This FAQ will concentrate wholly upon computer related security issues.
The discussions posted range from the likes of "What's such-and-such
system like?" and "What is the best software I can use to do so-and-so"
to "How shall we fix this particular bug?", although there is often a
low signal to noise ratio in the newsgroup (a problem which this FAQ
hopes to address).
The most common flamewars start when an apparent security novice posts a
message saying "Can someone explain how the such-and-such security hole
works?" and s/he is immediately leapt upon by a group of self appointed
people who crucify the person for asking such an "unsound" question in a
public place, and flame him/her for "obviously" being a cr/hacker.
Please remember that grilling someone over a high flame on the grounds
that they are "a possible cr/hacker" does nothing more than generate a
lot of bad feeling. If computer security issues are to be dealt with in
an effective manner, the campaigns must be brought (to a large extent)
into the open.
Implementing computer security can turn ordinary people into rampaging
paranoiacs, unable to act reasonably when faced with a new situation.
Such people take an adversarial attitude to the rest of the human race,
and if someone like this is in charge of a system, users will rapidly
find their machine becoming more restrictive and less friendly (fun?) to
use.
This can lead to embarrasing situations, eg: (in one university) banning
a head of department from the college mainframe for using a network
utility that he wasn't expected to. This apparently required a lot of
explaining to an unsympathetic committee to get sorted out.
A more sensible approach is to secure a system according to its needs,
and if its needs are great enough, isolate it completely. Please, don't
lose your sanity to the cause of computer security; it's not worth it.
usenet/comp.sources.misc/volume29
usenet/comp.sources.misc/volume30
usenet/comp.sources.misc/volume32
------------------------------------------------------------------
Q.2 What's the difference between a hacker and a cracker?
Lets get this question out of the way right now:
On USENET, calling someone a "cracker" is an unambiguous statement that
some person persistently gets his/her kicks from breaking from into
other peoples computer systems, for a variety of reasons. S/He may pose
some weak justification for doing this, usually along the lines of
"because it's possible", but most probably does it for the "buzz" of
doing something which is illicit/illegal, and to gain status amongst a
peer group.
Particularly antisocial crackers have a vandalistic streak, and delete
filestores, crash machines, and trash running processes in pursuit of
their "kicks".
The term is also widely used to describe a person who breaks copy
protection software in microcomputer applications software in order to
keep or distribute free copies.
On USENET, calling someone a "hacker" is usually a statement that said
person holds a great deal of knowledge and expertise in the field of
computing, and is someone who is capable of exercising this expertise
with great finesse. For a more detailed definition, readers are
referred to the Jargon File [Raymond].
In the "real world", various media people have taken the word "hacker"
and coerced it into meaning the same as "cracker" - this usage
occasionally appears on USENET, with disastrous and confusing results.
Posters to the security newsgroups should note that they currently risk
a great deal of flamage if they use the word "hacker" in place of
"cracker" in their articles.
NB: nowhere in the above do I say that crackers cannot be true hackers.
It's just that I don't say that they are...
------------------------------------------------------------------
Q.3 What is "security through obscurity"
Security Through Obscurity (STO) is the belief that any system can be
secure so long as nobody outside of its implementation group is allowed
to find out anything about its internal mechanisms. Hiding account
passwords in binary files or scripts with the presumption that "nobody
will ever find it" is a prime case of STO.
STO is a philosophy favoured by many bureaucratic agencies, and it used
to be a major method of providing "pseudosecurity" in computing systems.
Its usefulness has declined in the computing world with the rise of open
systems, networking, greater understanding of programming techniques, as
well as the increase in computing power available to the average person.
The basis of STO has always been to run your system on a "need to know"
basis. If a person doesn't know how to do something which could impact
system security, then s/he isn't dangerous.
Admittedly, this is sound in theory, but it can tie you into trusting a
small group of people for as long as they live. If your employees get
an offer of better pay from somewhere else, the knowledge goes with
them, whether the knowledge is replaceable or not. Once the secret gets
out, that is the end of your security.
Nowadays there is also a greater need for the ordinary user to know
details of how your system works than ever before, and STO falls down a
as a result. Many users today have advanced knowledge of how their
operating system works, and because of their experience will be able to
guess at the bits of knowledge that they didn't "need to know". This
bypasses the whole basis of STO, and makes your security useless.
Hence there is now a need is to to create systems which attempt to be
algorithmically secure (Kerberos, Secure RPC), rather than just
philosophically secure. So long as your starting criteria can be met,
your system is LOGICALLY secure.
Incidentally, "Shadow Passwords" (below) are sometimes dismissed as STO,
but this is incorrect, since (strictly) STO depends on restricting
access to an algorithm or technique, whereas shadow passwords provide
security by restricting access to vital data.
------------------------------------------------------------------
Q.4 What makes a system insecure?
Switching it on. The adage usually quoted runs along these lines:
"The only system which is truly secure is one which is switched off
and unplugged, locked in a titanium lined safe, buried in a concrete
bunker, and is surrounded by nerve gas and very highly paid armed
guards. Even then, I wouldn't stake my life on it."
(the original version of this is attributed to Gene Spafford)
A system is only as secure as the people who can get at it. It can be
"totally" secure without any protection at all, so long as its continued
good operation is important to everyone who can get at it, assuming all
those people are responsible, and regular backups are made in case of
hardware problems. Many laboratory PC's quite merrily tick away the
hours like this.
The problems arise when a need (such as confidentiality) has to be
fulfilled. Once you start putting the locks on a system, it is fairly
likely that you will never stop.
Security holes manifest themselves in (broadly) four ways:
1) Physical Security Holes.
- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.
A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.
Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.
2) Software Security Holes
- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.
The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.
(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine. The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)
New holes like this appear all the time, and your best hopes are to:
a: try to structure your system so that as little software as possible
runs with root/daemon/bin privileges, and that which does is known to
be robust.
b: subscribe to a mailing list which can get details of problems
and/or fixes out to you as quickly as possible, and then ACT when you
receive information.
>From: Wes Morgan <morgan@edu.uky.ms>
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need. Many packages include daemons or utilities which can reveal
> information to outsiders. For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user. Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
> <occasionally> tftpd, all of which can present security problems.
>
> Careful system administration is the solution. Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution. You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities
> tend to install/run everything in the package without asking you. Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.
3) Incompatible Usage Security Holes
- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.
Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind. It's
never too late to have a rethink, though.
Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.
4) Choosing a suitable security philosophy and maintaining it.
>From: Gene Spafford <spaf@cs.purdue.edu>
>The fourth kind of security problem is one of perception and
>understanding. Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it. Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.
------------------------------------------------------------------
Q.5 What tools are there to aid security
Q.6 ...and... where can I get these tools?
==================================================================
*** This is a section which has changed very rapidly over the past
*** few months; hence I am changing the format ever so slightly, in
*** order to allow for expansion - Alec
==================================================================
COPS Dan Farmer, et al.
Managed/largely written by Dan Farmer, COPS is a suite of shell scripts
which forms an extensive security testing system; there's a rudimentary
password cracker, and routines to check the filestore for suspicious
changes in setuid programs, others to check permissions of essential
system and user files, and still more to see whether any system software
behaves in a way which could cause problems.
The software comes in two versions - one written in Perl and one
(largely equivalent) written in shell scripts. The latest version is
very up-to-date on Unix Security holes.
COPS V1.04 is available for FTP from cert.org in pub/cops and
archive.cis.ohio-state.edu in pub/cops.
------------------------------------------------------------------
Crack Alec Muffett
UFC Michael Glad
Crack is a program written with one purpose in mind: to break insecure
passwords. It is probably the most efficent and friendly password
cracker that is publically available, with the ability to let the user
to specify precisely how to form the words to use as guesses at users
passwords.
It also has an inbuilt networking capability, allowing the load of
cracking to be spread over as many machines as are available on a
network, and it is supplied with an optimised version of the Unix crypt()
algorithm.
An even faster version of the crypt() algorithm, "UFC" by Michael Glad,
is freely available on the network, and the latest versions of UFC and
Crack are compatible and can be easily hooked together.
Crack v4.1f and UFC are available from: ftp.uu.net (137.39.1.9)
In the directory: /usenet/comp.sources.misc/volume28
As: crack/part01.Z to part05.Z ( 5 files )
And ufc-crypt/part01.Z & part02.Z ( 2 files )
NB: For people with access to a Connection Machine:
>From: glad@daimi.aau.dk (Michael Glad)
>
>A UNIX password cracker for the Thinking Machine CM/2 and CM/200
>Connection Machines is available for FTP from
>
> ftp.denet.dk:/pub/misc/cm200-UFC.tar.Z
>
> This is a password cracker for the Thinking Machines CM/2 and CM/200
> Connection Machines. It features
>
> o A standalone dictionary preprocessor accepting a
> language of rewrite rules compatible with the one
> found in Alec Muffets 'Crack' password cracker as of
> release 4.1f.
>
> o An optimized port of the UFC-crypt: a fast implementation
> of the UNIX crypt(3) function developed by Michael Glad and
> donated to the Free Software Foundation (FSF).
>
> o The password cracker itself. It supports restart of crashed
> runs and incremental use. Incremental use means that when
> you use a fixed dictionary, the cracker can maintain a status
> file of already cracked passwords and passwords considered
> uncrackable (because they've been tested in previous runs).
> Thus it only has to waste CPU cycles on new accounts and accounts
> with changed passwords.
>
> o When run with a _large_ dictionary (a 1 million word dictionary
> obtained by preprocessing /usr/dict/words), the cracker can
> test in excess of 50,000 passwords a second on a CM/200 with
> 8192 processors.
------------------------------------------------------------------
CrackLib Alec Muffett
Cracklib is a C LIBRARY containing a routine which may be wired into all
sorts of "passwd"-like programs; not just Unix, but with a little effort
it could probably go onto VMS (this is being worked upon), or many other
systems.
Using "CrackLib" allows you to wire proactive password checking into
_any_ of your applications; it is an offshoot of the the version 5
"Crack" software, and contains a considerable number of ideas nicked
from the new software.
CrackLib was posted to "comp.sources.misc", and therefore available from
any major usenet archive. A reference copy (+ large dictionary) can be
FTP'ed from:
black.ox.ac.uk:~ftp/src/security/cracklib25.tar.Z
NB: if you search for CrackLib on "Archie", care should be taken to get
the package from a comp.sources.misc archive; beware confusing it with a
package of the same name, which was hacked into "npasswd".
------------------------------------------------------------------
NPasswd Clyde Hoover
Passwd+ Matt Bishop
Shadow John F. Haugh II
Passwd+ & NPasswd: these programs are written to redress the balance in
the password cracking war. They provide replacements for the standard
"passwd" command, but prevent a user from selecting passwords which are
easily compromised by programs like Crack.
The usual term for this type of program is a 'fascist' password program.
NPasswd: Currently suffering from being hacked about by many different
people, in order to provide compatibility for System V based systems,
NIS/YP, shadow password schemes, etc. Version 2.0 is in the offing, but
many versions exist in many different configurations.
Passwd+: "alpha version, update 3" - beta version due soon. Available
from dartmouth.edu as pub/passwd+.tar.Z
Shadow: is a set of program and function replacements (compatible with
most Unixes) which implements shadow passwords, ie: a system where the
plaintext of the password file is hidden from all users except root,
hopefully stopping all password cracking attempts at source. In
combination with a fascist passwd frontend, it should provide a good
degree of password file robustness.