Académique Documents
Professionnel Documents
Culture Documents
This FAQ will concentrate wholly upon computer related security issues.
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.
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.
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.
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...
Security Through Obscurity (STO) is the belief that a system of any sort
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.
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.
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."
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 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 EMACS) is described in [Stoll].)
New holes like this appear all the time, and your best hopes are to:
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.
1) "COPS"
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.
2) "Crack" (+ "UFC").
This program suite (by John F Haugh II) 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.
6) SecureLib
7) SPI
That depends on your point of view. Some people have complained that
giving unrestricted public access to programs like COPS and Crack is
irresponsible because the "baddies" can get at them easily.
Alternatively, you may believe that the really bad "baddies" have had
programs like this for years, and that it's really a stupendously good
idea to give these programs to the good guys too, so that they may check
the integrity of their system before the baddies get to them.
So, who wins more from having these programs freely available? The good
guys or the bad ? You decide, but remember that less honest tools than
COPS and Crack tools were already out there, and most of the good guys
didn't have anything to help.
COPS:
Crack/UFC:
Crack v4.1f and UFC Patchlevel 1. Available from any major USENET
archive (eg: ftp.uu.net) in volume 28 of comp.sources.misc.
NPasswd:
Passwd+:
"alpha version, update 3" - beta version due soon. Available from
dartmouth.edu as pub/passwd+.tar.Z
Shadow:
TCP Wrappers:
cert.sei.cmu.edu: pub/network_tools/tcp_wrapper.shar
ftp.win.tue.nl: pub/security/log_tcp.shar.Z
Securelib:
The latest version of securelib is available via anonymous FTP from the
host "eecs.nwu.edu". It is stored in the file "pub/securelib.tar".
Some crackers might think that it's "really neat" to hop over 6 Internet
machines, 2 gateways and an X.25 network just to knock on the doors of
some really famous company or institution (eg: NASA, CERN, AT+T, UCB).
Think of it as inter-network sightseeing.
This sort of thing happens all the time, and not just in universities.
One solution is in education. Do not let your users develop attitudes
like this one:
>From: Ed DeHart
> The Computer Emergency Response Team (CERT) was formed by the Defense
> Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal
> point for the computer security concerns of Internet users. The
> Coordination Center for the CERT is located at the Software Engineering
> Institute, Carnegie Mellon University, Pittsburgh, PA.
...and also, the umbrella group "FIRST", which mediates between the
incident handling teams themselves...
For more information on these sort of topics, see the Gateway paper by
[Cheswick], below.
You shouldn't use them for a variety of reasons, mostly involving bugs
in the Unix kernel. Here are a few of the more well known problems,
some of which are fixed on more recent operating systems.
2) Many kernels suffer from a race condition which can allow you to
exchange the shellscript for another executable of your choice between
the times that the newly exec()ed process goes setuid, and when the
command interpreter gets started up. If you are persistent enough, in
theory you could get the kernel to run any program you want.
3) The IFS bug: the IFS shell variable contains a list of characters to
be treated like whitespace by a shell when parsing command names. By
changing the IFS variable to contain the "/" character, the command
"/bin/true" becomes "bin true".
All you need do is export the modified IFS variable, install a command
called "bin" in your path, and run a setuid script which calls
"/bin/true". Then "bin" will be executed whilst setuid.
a) Put a setuid wrapper in "C" around the script, being very careful
to reset IFS and PATH to something sensible before exec()ing the
script. If your system has runtime linked libraries, consider the
values of the LD_LIBRARY_PATH also.
For example, on many systems you will find a unpassworded user "sync",
which allows the sysman to sync the disks without being logged in. This
appears to be both safe and innocuous.
The problem with this arises if your system is one of the many which
doesn't do checks on a user before authorising them for (say) FTP. A
cracker might be able to connect to your machine for one of a variety of
FTP methods, pretending to be user "sync" with no password, and then
copy your password file off for remote cracking.
Q.14 What security holes are associated with X-windows (and other WMs)?
Lots, some which affect use of X only, and some which impact the
security of the entire host system.
I would prefer not to go into too much detail here, and would refer any
reader reader looking for detailed information to the other FAQ's in
relevant newsgroups. (comp.windows.*)
One point I will make is that X is one of those packages which often
generates "Incompatible Usage" security problems, for instance the
ability for crackers to run xsessions on hosts under accounts with no
password (eg: sync), if it is improperly set up. Read the question
about unpassworded accounts in this FAQ.
Lots, mostly to do with who you export your disks to, and how. The
security of NFS relies heavily upon who is allowed to mount the files
that a server exports, and whether they are exported read only or not.
The exact format for specifying which hosts can mount an exported
directory varies between Unix implementations, but generally the
information is contained within the file "/etc/exports".
This file contains a list of directories and for each one, it has a
series of either specific "hosts" or "netgroups" which are allowed to
NFS mount that directory. This list is called the "access list".
The exports file also contains information about whether the directory
is to be exported as read-only, read-write, and whether super-user
access is to be allowed from clients which mount that directory.
The important point to remember is that if the access list for a
particular directory in /etc/exports contains:
1) <nothing>
If the netgroup:
If you meant to export the directory to the host "athena" but actually
type "ahtena", the word "ahtena" is taken as a netgroup name, is found
to be an empty netgroup, and thus the directory can be mounted by
anyone, anywhere.
So, if you aren't careful about what you put into /etc/exports and
/etc/netgroup you could find that a user with a PC could
Disclaimer: The above information may not be true for all platforms
which provide an NFS serving capability, but is true for all of the ones
in my experience (AEM). It should be noted that the SAFE way to create
an "empty" netgroup entry is:
ngname (-,-,-)
You can't. The key word here is GENERATE. Once an algorithm for
creating passwords is specified using upon some systematic method, it
merely becomes a matter of analysing your algorithm in order to find
every password on your system.
Unless the algorithm is very subtle, it will probably suffer from a very
low period (ie: it will soon start to repeat itself) so that either:
alec7 - it's based on the users name (& it's too short anyway)
tteffum - based on the users name again
gillian - girlfiends name (in a dictionary)
naillig - ditto, backwards
PORSCHE911 - it's in a dictionary
12345678 - it's in a dictionary (& people can watch you type it easily)
qwertyui - ...ditto...
abcxyz - ...ditto...
0ooooooo - ...ditto...
Computer - just because it's capitalised doesn't make it safe
wombat6 - ditto for appending some random character
6wombat - ditto for prepending some random character
merde3 - even for french words...
mr.spock - it's in a sci-fi dictionary
zeolite - it's in a geological dictionary
ze0lite - corrupted version of a word in a geological dictionary
ze0l1te - ...ditto...
Z30L1T3 - ...ditto...
I hope that these examples emphasise that ANY password derived from ANY
dictionary word (or personal information), modified in ANY way,
constitutes a potentially guessable password.
For more detailed information in the same vein, you should read the
APPENDIX files which accompany Crack [Muffett].
Because they are the first line of defence against interactive attacks
on your system. It can be stated simply: if a cracker cannot interact
with your system(s), and he has no access to read or write the
information contained in the password file, then he has almost no
avenues of attack left open to break your system.
This is also why, if a cracker can at least read your password file (and
if you are on a vanilla modern Unix, you should assume this) it is so
important that he is not able to break any of the passwords contained
therein. If he can, then it is also fair to assume that he can (a) log
on to your system and can then (b) break into "root" via an operating
system hole.
Most people ask this at one time or another, worried that programs like
Crack will eventually grow in power until they can do a completely
exhaustive search of all possible passwords, to break into a specific
users' account - usually root.
Then the size of the set of all valid passwords is: (in base 62)
100000 +
1000000 +
10000000 +
100000000 =
---------
111100000 (base 62)
However, it's still MUCH more efficient for a cracker to get a copy of
"Crack", break into ANY account on the system (you only need one), log
onto the machine, and spoof his way up to root priviledges via operating
systems holes.
Take comfort from these figures. If you can slam the door in the face
of a potential crackers with a robust password file, you have sealed
most of the major avenues of attack immediately.
Books:
A little dated for modern matters, but still a very good book on the
basics of Unix security.
[Stoll]
The Cuckoo's Egg
I believe that this program was aired on the BBC's "HORIZON" program,
and thus will be available from BBC Enterprises, but I haven't checked
this out yet - AEM
[Raymond] (Ed.)
The New Hackers Dictionary/Online Jargon File
[Gasser]
Building a Secure Computer System.
Papers:
[Curry]
Improving the Security of your Unix System.
[Klein]
Foiling the Cracker: A Survey of, and Improvements to, Password Security.
[Cheswick]
The Design of a Secure Internet Gateway.
[Cheswick]
An Evening With Berferd: in which a Cracker is Lured, Endured and Studied.
Funny and very readable, somewhat in the style of [Stoll] but more
condensed. research.att.com:/dist/berferd.ps
[Bellovin89]
Security Problems in the TCP/TP Protocol Suite.
[Bellovin91]
Limitations of the Kerberos Authentication System
[Muffett]
Crack documentation.
[Farmer]
COPS
[CERT]
maillists/advisories/clippings
[OpenSystemsSecurity]
A notorious (but apparently quite good) document, which has been dogged
by being in a weird postscript format.
[RFC-1244]
Site Security Handbook
[USENET]
comp.virus: for discussions of virii and other nasties, with a PC bent.
comp.unix.admin: for general administration issues
comp.unix.<platform>: for the hardware/software that YOU use.
comp.protocols.tcp-ip: good for problems with NFS, etc.
If you have an experience that you wish to share, please send it to the
editors. It'll boost your karma no end.
---------------------------------------------------------------------------
aem@aber.ac.uk: The best story I have is of a student friend of mine
(call him Bob) who spent his industrial year at a major computer
manufacturing company. In his holidays, Bob would come back to college
and play AberMUD on my system.
Part of Bob's job at the company involved systems management, and the
company was very hot on security, so all the passwords were random
strings of letters, with no sensible order. It was imperative that the
passwords were secure (this involved writing the random passwords down
and locking them in big, heavy duty safes).
One day, on a whim, I fed the MUD persona file passwords into Crack as a
dictionary (the passwords were stored plaintext) and then ran Crack on
our systems password file. A few student accounts came up, but nothing
special. I told the students concerned to change their passwords - that
was the end of it.
Being the lazy guy I am, I forgot to remove the passwords from the Crack
dictionary, and when I posted the next version to USENET, the words went
too. It went to the comp.sources.misc moderator, came back over USENET,
and eventually wound up at Bob's company. Round trip: ~10,000 miles.
Being a cool kinda student sysadmin dude, Bob ran the new version of
Crack when it arrived. When it immediately churned out the root
password on his machine, he damn near fainted...
The moral of this story is: never use the same password in two different
places, and especially on untrusted systems (like MUDs).
--
aem@aber.ac.uk aem@uk.ac.aber aem%aber@ukacrl.bitnet mcsun!uknet!aber!aem
- send (cryptographic) comp.sources.misc material to: aem@aber.ac.uk -