greg@oreo.berkeley.edu (Greg) (11/09/88)
Now that we've killed all copies of the Internet virus and fixed sendmail and fingerd, it's time to thinking about stopping future viruses. I'm sure that this virus is an inspiration and a dare to a lot of bored hackers out there. The fact is that the virus missed a lot of opportunities for infiltration, opportunities that any determined programmer could recognize. Despite these imperfections, and despite crashing many of the systems it spread to, it spread to 6,000 sites in 18 hours. Without its fatal bug, it would have gone everywhere within a week or two. Here is some of what needs to be done: 1. Protect the password file. On most Unix systems that I've seen, /etc/passwd is publicly readable. There is no reason for this. It's amusing to have encrypted passwords that anyone can look at, but it's also a security hole. Undoubtedly, the virus guessed passwords by reading the password file directly and encrypting on its own. Make the virus work to guess passwords. 2. Strengthen crypt(3). The password encryption routine, crypt(3), uses DES, a sound encryption algorithm. However, one of the design goals of crypt(3) was to retard password guessing, and in this direction it has misfeatures. The routine is deliberately unoptimized to be slow. Still, one DES pass was too fast for comfort, so the routine encrypts a blank field with the password as key 25 times. This is the wrong approach. The virus either did or could have had a private, optimized encryption routine. Furthermore, the virus had substantial computer power available, typically a whole ring of suns, to attack a given password file. I am told that someone has written a fast crypt(3) that encrypts 40 passwords per second, which is fast enough to encrypt /usr/dict/words in 1 minute on a ring of 10 suns. The obvious solution is to optimize crypt(3) as much as possible, and then decide how many encryption passes there should be. Since 40 x 25 = 1000, I recommend several thousand passes. For good measure it could encrypt a block larger than a 8-byte blank field. For example, you could chain encrypt a longer string of bytes and put a checksum of the string in /etc/password. 3. Protect home directories. Like the password file, home user directories are publicly readable by default on a lot of Unix machines. This virus learned hostnames from checking .rhosts files. A stronger virus could also analyze mbox files and make keyword searches. User files could let it know which user passwords are valuable and which are a waste of time. The read status of user directories is the most obvious and inviting Unix security bug there is. In addition to its utility to viruses, it allows even unskilled users to snoop, and it demonstrates to them that Unix security is poor. It's time to change the default setting for the access status of home directories. 4. Eliminate unnecessary .rhosts files This virus only used .rhosts files to learn host names and user names. It could have made the likely inference that if Amy is in Tom's .rhosts file, Tom is in Amy's .rhosts file too. But it didn't do that. .rhosts files are very convenient, but they make us place a lot of trust in other computers on the network. Old .rhosts files are dry tinder waiting to catch fire. We should have default expirations of .rhosts entries between different sites. -- Greg
koreth@ssyx.ucsc.edu (Steven Grimm) (11/09/88)
In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >On most Unix systems that I've seen, /etc/passwd is publicly readable. >There is no reason for this. Unless you're proposing adding another file with usernames and uids, /bin/ls will stop telling you who owns files if /etc/passwd isn't readable...
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/10/88)
In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes:
Now that we've killed all copies of the Internet virus and
fixed sendmail and fingerd, it's time to thinking about
stopping future viruses.
Here is some of what needs to be done
1. Protect the password file.
On most Unix systems that I've seen, /etc/passwd is publicly
readable. There is no reason for this. It's amusing to
have encrypted passwords that anyone can look at, but it's
also a security hole. Undoubtedly, the virus guessed
passwords by reading the password file directly and
encrypting on its own. Make the virus work to guess
passwords.
This problem was announced in 1976 and fixed in most secure
systems [I did it for NSA]. ATT has shadow (hidden) passwords
in System V Relase 3.2. Other vendors: go thou and do likewise.
The ONLY problem, applications programs can't use password
validation for authentication then. Of course a Yellow Pages RPC
call could be used:
isvalidpasswd(use, passwd);
2. Strengthen crypt(3).
The password encryption routine, crypt(3), uses DES, a sound
encryption algorithm. However, one of the design goals of
crypt(3) was to retard password guessing, and in this
direction it has misfeatures. The routine is deliberately
unoptimized to be slow. Still, one DES pass was too fast
for comfort, so the routine encrypts a blank field with the
password as key 25 times.
This is the wrong approach. The virus either did or could
have had a private, optimized encryption routine.
Furthermore, the virus had substantial computer power
available, typically a whole ring of suns, to attack a given
password file. I am told that someone has written a fast
crypt(3) that encrypts 40 passwords per second, which is
fast enough to encrypt /usr/dict/words in 1 minute on a ring
of 10 suns.
The obvious solution is to optimize crypt(3) as much as
possible, and then decide how many encryption passes there
should be. Since 40 x 25 = 1000, I recommend several
thousand passes. For good measure it could encrypt a block
larger than a 8-byte blank field. For example, you could
chain encrypt a longer string of bytes and put a checksum of
the string in /etc/password.
Still a bad approach. A work factor assumes that one has do do
this on line. When Ken Thompson did his password attack he
sucked the password file back to his home system and did it
there. [Nowdays one could use a CRAY]. When I did my password
attacks I encrypted the dictionary FIRST. Then it was one
encrypt and a fgrep. From start to finish (copy of /etc/passwd
until printing of list of lognames and password was 45 minutes!).
3. Protect home directories.
Like the password file, home user directories are publicly
readable by default on a lot of Unix machines. This virus
learned hostnames from checking .rhosts files. A stronger
virus could also analyze mbox files and make keyword
searches. User files could let it know which user passwords
are valuable and which are a waste of time.
The read status of user directories is the most obvious and
inviting Unix security bug there is. In addition to its
utility to viruses, it allows even unskilled users to snoop,
and it demonstrates to them that Unix security is poor.
It's time to change the default setting for the access
status of home directories.
Umask was invented for this purpose! In a paranoid installation
umask is set to 077. Super paranoid it is 0777!
4. Eliminate unnecessary .rhosts files
This virus only used .rhosts files to learn host names and
user names. It could have made the likely inference that if
Amy is in Tom's .rhosts file, Tom is in Amy's .rhosts file
too. But it didn't do that.
.rhosts files are very convenient, but they make us place a
lot of trust in other computers on the network. Old .rhosts
files are dry tinder waiting to catch fire. We should have
default expirations of .rhosts entries between different
sites.
See comments previously on the net about the breakin at Stanford
two years ago. See also below.
I might add:
5. Programs to search the file system for "suspicious" events.
I have a package audit to very permissions, ownershps, lenght and
check sum of a set of files. [Sorry, ATT Proprietary.] I have
designs of others to check for corruped files [more severe check
sums -- can't be forged] and look for security holes.
There are companies that sell similar security suites. There are
books that explain and give shell scripts.
Security is requires active and continuing work by a system
administrator. All the security mechanisms and protections in
the world won't help if the system administrator is unwilling to
use them. Nor, if the system administrator makes a mistake. Or,
if some one delibately unprocts things.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.comgreg@oreo.berkeley.edu (Greg) (11/10/88)
In article <5420@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: >In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >>On most Unix systems that I've seen, /etc/passwd is publicly readable. >>There is no reason for this. >Unless you're proposing adding another file with usernames and uids, /bin/ls >will stop telling you who owns files if /etc/passwd isn't readable... This is minor problem. I can think of two quick solutions: 1) Make /etc/passwd publicly readable, but put the encrypted passwords somewhere else. 2) Have ls setuid when it wants to read /etc/password, but not when it reads the directory itself. -- Greg
rang@cpsin3.cps.msu.edu (Anton Rang) (11/10/88)
In article <16722@agate.BERKELEY.EDU>, koreth@ssyx.ucsc.edu (Steven Grimm) writes: >In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >>On most Unix systems that I've seen, /etc/passwd is publicly readable. >>There is no reason for this. > >Unless you're proposing adding another file with usernames and uids, /bin/ls >will stop telling you who owns files if /etc/passwd isn't readable... So we should fix 'ls' too. Sun is slowly moving in this direction. Under SunOS 4.0, there is an option which causes the password file to be split into two files: /etc/passwd, which contains all the information except the actual encrypted password, and /etc/security/passwd.adjunct (or something like that) which is NOT world-readable and contains the encrypted passwords. (Of course, it doesn't always work right, but that's another story.) It's just plain STOOOPID to leave the passwords readable. Why take chances with your system? +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
guy@auspex.UUCP (Guy Harris) (11/10/88)
>On most Unix systems that I've seen, /etc/passwd is publicly readable. >There is no reason for this. Actually, there is a reason, namely: 1) there are fields in the password file that are used by other programs that need not and should not be privileged (e.g., "ls") and 2) UNIX systems tend not to be distributed with support for "shadow" password files, with the real passwords in a non-publicly-readable file. "/etc/passwd" should, at least in all UNIX implementations I know of, be publicly readable - doing chmod go-r /etc/passwd may make your system more secure, but it will also break several programs. (There are ways, other than a "shadow" password file, to handle this - for instance, "getpwent()" and company could make queries to a privileged server process. The point is that most UNIX systems work as they always have, reading user names, etc. from "/etc/passwd", possibly with an indirection off to something like the Yellow Pages.)
aad@stpstn.UUCP (Anthony A. Datri) (11/10/88)
In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: > >On most Unix systems that I've seen, /etc/passwd is publicly readable. >There is no reason for this. It's amusing to have encrypted passwords >that anyone can look at, but it's also a security hole. I guess you don't want to use ~ in csh, nor do you want ls -l to give you user names instead of user numbers. >4. Eliminate unnecessary .rhosts files I'll agree with you there. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) stpstn!aad
greg@skippy.berkeley.edu (Greg) (11/10/88)
In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: > The obvious solution is to optimize crypt(3) as much as > possible, and then decide how many encryption passes there > should be. Since 40 x 25 = 1000, I recommend several > thousand passes. ... >Still a bad approach. A work factor assumes that one has do do >this on line. When Ken Thompson did his password attack he >sucked the password file back to his home system and did it >there. [Nowdays one could use a CRAY]. When I did my password >attacks I encrypted the dictionary FIRST. Firstly, there is no way that a virus would beam all passwords to one central computer to be processed there. Secondly, your approach will no longer work with the advent of the salt, the 12 random bits stored in the clear with the encrypted password. You would have to encrypt the dictionary 4096 times, or be content with cracking a much smaller portion of the password file. It would be good to expand the salt to 36 bits, just to make sure that you can't preencrypt even a small dictionary. Lastly, I'm not arguing that my suggestions will prevent password guessing completely, just that it will make it harder. I limited my suggestions to easy fixes for Unix. -- Greg
greg@skippy.berkeley.edu (Greg) (11/10/88)
In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >Security is requires active and continuing work by a system >administrator. All the security mechanisms and protections in >the world won't help if the system administrator is unwilling to >use them. Nor, if the system administrator makes a mistake. Or, >if some one delibately unprocts things. I agree with this. However, if continual vigilance is your only answer, then you are asking the wrong question, at least as far as Unix systems are concerned. The question is not "How do we make Unix secure?", but "How do we get the most security with the least effort?" Many system managers just don't have the time or desire to turn their computers into fortresses. -- Greg
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/10/88)
In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: |In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: | Now that we've killed all copies of the Internet virus and | fixed sendmail and fingerd, it's time to thinking about | stopping future viruses. | | Here is some of what needs to be done | |1. Protect the password file. | | On most Unix systems that I've seen, /etc/passwd is publicly | readable. There is no reason for this. It's amusing to | have encrypted passwords that anyone can look at, but it's | also a security hole. | |This problem was announced in 1976 and fixed in most secure |systems [I did it for NSA]. ATT has shadow (hidden) passwords |in System V Relase 3.2. Other vendors: go thou and do likewise. |The ONLY problem, applications programs can't use password |validation for authentication then. Of course a Yellow Pages RPC |call could be used: I began working on a login replacement Friday. It is virtually complete and only needs minor tweaking. It has most of the features of the better logins - subsystem logins, console-only root logins, environmental variables set from login: response, etc. I will be posting the code to alt.sources and pubnet.sources some time tonight to solicit comments and suggestions. Unfortunately, I also need a su(1) and passwd(1) replacement. I think I need some other stuff as well, but I don't remember ... The resulting code will be public domain and freely reproducible without any restrictions. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `No, Honey'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
allen@sulaco.UUCP (Allen Gwinn) (11/10/88)
In article <5420@saturn.ucsc.edu>, koreth@ssyx.ucsc.edu (Steven Grimm) writes: > In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: > >On most Unix systems that I've seen, /etc/passwd is publicly readable. > >There is no reason for this. > > Unless you're proposing adding another file with usernames and uids, /bin/ls > will stop telling you who owns files if /etc/passwd isn't readable... As a matter of fact, the next release of System V has a "shadow" password file to complement /etc/passwd. It is not readable by the world. The passwords in /etc/passwd are dummies (the string ":np:" or whatever the password was in /etc/passwd prior to conversion). Should put an end to password hacking as we know it :-) -- Allen Gwinn ...sulaco!allen Disclaimer: The facts stated are my own. "Remember, facts are stupid things." - Brad Schoening (uiucdcs!schoenin)
jbn@glacier.STANFORD.EDU (John B. Nagle) (11/10/88)
In article <16768@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >Firstly, there is no way that a virus would beam all passwords to >one central computer to be processed there. No reason that can't be done. Richey did it that way. >Secondly, your approach will no longer work with the advent of the >salt, the 12 random bits stored in the clear with the encrypted >password. You would have to encrypt the dictionary 4096 times, or be >content with cracking a much smaller portion of the password file. It >would be good to expand the salt to 36 bits, just to make sure that you >can't preencrypt even a small dictionary. It's not clear that the "salt" trick helps all that much. Bear in mind that Dennis Mumaugh works for NSA. He's telling us that the UNIX password encryption system is fundamentally insecure. Pay attention, people. John Nagle
honey@mailrus.cc.umich.edu (peter honeyman) (11/10/88)
Dennis L. Mumaugh writes: >... I encrypted the dictionary FIRST. Then it was one >encrypt and a fgrep. From start to finish (copy of /etc/passwd >until printing of list of lognames and password was 45 minutes!). where did you store the gigabyte file? how long did it take to generate it? (25,000 word dictionary, 4,096 salts, 11 byte output each.) peter
ok@quintus.uucp (Richard A. O'Keefe) (11/10/88)
In article <16768@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >Secondly, your approach will no longer work with the advent of the >salt, the 12 random bits stored in the clear with the encrypted >password. You would have to encrypt the dictionary 4096 times, or be >content with cracking a much smaller portion of the password file. It >would be good to expand the salt to 36 bits, just to make sure that you >can't preencrypt even a small dictionary. I'm afraid the salt is not much protection. I'm not going to explain why, but read the crypt(3) manual page carefully...
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/11/88)
In article <778@mailrus.cc.umich.edu>, honey@mailrus.cc.umich.edu (peter honeyman) writes: > where did you store the gigabyte file? how long did it take to > generate it? (25,000 word dictionary, 4,096 salts, 11 byte output > each.) You don't need to use all 4096 salts; you simply need the ones used on the target system. On my system, for example, that reduces the storage needed by a factor of about 20, which makes it easily manageable. One key mistake made in the encryption algorithm design is that a cracker can take shortcuts to speed up the encryption. One of the slowest parts of DES (in software) is the initial and final permutations. These are inverses of each other, however, which means that when iterating DES the inverse permutation of step I and the permutation of step I+1 cancel out, and can be omitted. Thus, only one initial permutation, and one final permutation, are needed, rather than 25 of each. (This isn't my idea, by the way; I know I've seen it elsewhere, probably in the fdes package posted to the net a few years ago.)
henry@utzoo.uucp (Henry Spencer) (11/11/88)
In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: >1. Protect the password file. As a number of people have already mentioned, this is a lousy idea because some of the other information in there is important. The thing to do is to get the passwords out of there and off somewhere else, somewhere that is protected. For good measure, put random pseudo-passwords in /etc/passwd to waste the time of would-be crackers. >2. Strengthen crypt(3). >...The obvious solution is to optimize crypt(3) as much as possible, and >then decide how many encryption passes there should be... There are two problems with this. First, while the password encryption algorithm ought to be slow enough to interfere with brute-force searches, it *must* be fast enough to run in a tolerable length of time on the small, slow machines that still run many Unixes. This is a difficult compromise. A cheaper way to make brute-force searches unproductive is to work hard on convincing users to use passwords that such a search won't find easily. Passwd should (and does, on some systems) simply refuse to allow anything in /usr/dict/words as a password, which instantly kills the usefulness of dictionary-based searches. The second problem is that multiple encryption isn't necessarily any better than single encryption; it's sometimes possible to devise an algorithm that does the multiple encryption in a single step. I don't know that anybody has done this for DES, but the possibility should not be ignored. >The read status of user directories is the most obvious and inviting >Unix security bug there is... Unfortunately, it is also very valuable to many sites, hence many people are reluctant to do this. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/11/88)
In article <17828@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > Bear in mind that Dennis Mumaugh works for NSA. He's telling us >that the UNIX password encryption system is fundamentally insecure. Pay >attention, people. > > John Nagle John is a bit out of date: I used to work for NSA. I changed employment in 1984 and I now work for ATT, Data Systems Group, in their top tier UNIX System software support group. Hence my knowledge on UNIX security can be out of date with respect to the US Government. Also much of the tiger team was done in 1976 and my security work was done in 1978-81 and then some later in 1983. As far as the ATT UNIX System V I am not authorized to comment on security aspects except to mention that System V Release 3.2 does use shadow passwords so brute force decrytpion is possible only through administratoir error. 3.2 also prevents shells being executed by setuid programs (e.g. using the system(3) feature). When I WAS working for NSA we started re-eingineering the password system to allow pass phrases and a rather strict censor for determining whether a pass-phrase would be accepted. Even the current System V does have some criteria and it also does password ageing. BUT most Berkely derived systems haven't kept pace. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
maart@cs.vu.nl (Maarten Litmaath) (11/11/88)
In article <16756@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes: \In article <5420@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: \>Unless you're proposing adding another file with usernames and uids, /bin/ls \>will stop telling you who owns files if /etc/passwd isn't readable... \... \2) Have ls setuid when it wants to read /etc/password, but not when it \reads the directory itself. Yeah! Another setuid program! Probably a setuid SHELL SCRIPT! Hey guys, let's make /bin/sh setuid root, because [...] -- George Bush: |Maarten Litmaath @ VU Amsterdam: Capt. Slip of the Tongue |maart@cs.vu.nl, mcvax!botter!maart
jbs@fenchurch.mit.edu (Jeff Siegal) (11/11/88)
In article <10835@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >You don't need to use all 4096 salts; you simply need the ones used >on the target system. It turns out that, due to a (apparent) bug in passwd.c, at least on Berkeley systems, only about 400 salts ever get used. Jeff Siegal
friedl@vsi.COM (Stephen J. Friedl) (11/11/88)
In article <16722@agate.BERKELEY.EDU>, greg@oreo.berkeley.edu (Greg) writes: > [how to prevent future virii] > > 1. Protect the password file. > > On most Unix systems that I've seen, /etc/passwd is publicly readable. > There is no reason for this. By default, yes there is. Many commands use the password file for the uid<-->uname (and gecos) lookups, and simply changing the mode of /etc/passwd will break a lot of systems. System V Release 3.2 and beyond address this by moving the password portion of /etc/passwd into /etc/shadow. This way, /etc/passwd is readable and /etc/shadow is not. Steve -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl ------------Nancy Reagan on the worm: "Just say OH NO!"------------
honey@mailrus.cc.umich.edu (peter honeyman) (11/11/88)
Steven M. Bellovin, my favorite coauthor, writes: >In article <778@mailrus.cc.umich.edu>, honey@mailrus.cc.umich.edu (peter honeyman) writes: >> where did you store the gigabyte file? how long did it take to >> generate it? (25,000 word dictionary, 4,096 salts, 11 byte output >> each.) > >You don't need to use all 4096 salts; you simply need the ones used >on the target system. On my system, for example, that reduces the >storage needed by a factor of about 20, which makes it easily manageable. steve, good buddy, that's not what he said. generating only the ones you need is the same as generating them as you need them. sure, you can drag old answers around with you and such, but eventually you end up with a gigabyte file. hell, i don't know if this is what he did. that's why i asked. peter
brad@looking.UUCP (Brad Templeton) (11/11/88)
It's well known how to have a secure system. Don't have any lines into the system. The lesson to be learned from this is the real world, where we want these lines, is that would shouldn't have humungo-complex-buggy programs talking to the outside world. We should apply the ring security kernel concept to our communication programs, and then we can make our own private decisions inside the system about how to trade off security for convenience. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
anders@suadb.UUCP (Anders Bj|rnerstedt) (11/11/88)
I would like to add:
6. A less blunt use of the set-user-id mechanism.
Sendmail apparently needs to do rights amplification,
but I dont see why it needs superuser rights. The uucp
binaries have thier own owner/domain "uucp". Why cant
the binaries related to mail have a similar domain "mail".
I am sure there are other suid programs which are today
owned by root, but which dont actually need full superuser
priviliges.
7. It should be *possible* to physically write lock filesystems
including the root file system. The disk write lock could
perhaps be used, but the fact that it is tied to a device
usually creates problems. What is needed is a physical togle
for a logical concept: secure filesystems. It should be
possible to place stable things like system programs in file
systems marked "secure". The kernel (which would itself be
placed in a secure filesystem) would only allow writes to
a secure filesystem if a physical togle was in the "open"
position. Normally the togle would be in the closed position.
The togle is opened only when changes are really needed and
requires a person to physically do it on-site. Sometimes this
would be perceived as an inconvenience, but for those willing
to pay the price it should be possible
------------------------------------
Anders Bjornerstedt
Department of Computer & Systems Sciences
University of Stockholm
S-106 91 Stockholm
Sweden
INTERNET: anders@sisu.se OR anders%sisu.se@uunet.uu.net
UUCP:{uunet,mcvax,cernvax}!enea!sics!sisus!anders.dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/12/88)
In article <778@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) writes: >Dennis L. Mumaugh writes: >>... I encrypted the dictionary FIRST. Then it was one >>encrypt and a fgrep. From start to finish (copy of /etc/passwd >>until printing of list of lognames and password was 45 minutes!). > >where did you store the gigabyte file? how long did it take to >generate it? (25,000 word dictionary, 4,096 salts, 11 byte output >each.) > I haven't done this in years, at the time I had a 300 meg disk to work with. Today my approach would be to analyze the salt and crypt to verify just which salts are valid [some are not valid or are rare]. Then I would build the dictionary of ~80000 entries plus variants. Then I would encrypt it with all salts. I have 4 3b20's and 30 3B2's and some have gigabytes of SCSI disks. [ 6250 tapes with 200 ips drives are also a possibilitiy]. Hence I can split the data into several places. All of this is done in advance. When the password file [or shadow] is found I split it into equivalence sets and send the entries for each set to the appropriate computer for munching. Hence to time to crack is the time to search each file. Don't forget that your estimate is off a bit too. I need the 13 byte encrypted version, a separator and then the plain text. Thus it is 22 bytes x 80,000 x 4096 or 7,208,960,000 bytes of storage. With say 20 cpus and only 400 real salts I need 36,044,800 bytes per machine. I can automate almost all of this and thanks to RFS and LAN's communcations isn't the problem. The time is that to fgrep the 36 Meg file on each machine. That runs about an hour depending on load and disk performance. The major point is that properly prepared one CAN crack passwords in less than an hour given adequate resources. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
jlh@loral.UUCP (Physically Pffft) (11/12/88)
In article <17828@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > Bear in mind that Dennis Mumaugh works for NSA. He's telling us >that the UNIX password encryption system is fundamentally insecure. Pay >attention, people. > > John Nagle Whooptideedo. We have people here in tech pubs that have access to Usenet but wouldn't know the difference between a csh and a sea shell. Unless you know for a fact that the guy is on the engineering staff, and in a relevent department, you can't guage their postings based on the company/organization they work for. Isn't that why we make our disclaimers as stupid as possible instead of legally accurate? Jim Disclaimer: While I am smart enough to read news and use the 'F' command, that doesn't imply I know anything about UNIX. -- Jim Harkins jlh@loral.cts.com Loral Instrumentation, San Diego
jerry@olivey.olivetti.com (Jerry Aguirre) (11/12/88)
In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >Still a bad approach. A work factor assumes that one has do do >this on line. When Ken Thompson did his password attack he >sucked the password file back to his home system and did it >there. [Nowdays one could use a CRAY]. When I did my password >attacks I encrypted the dictionary FIRST. Then it was one >encrypt and a fgrep. From start to finish (copy of /etc/passwd >until printing of list of lognames and password was 45 minutes!). Several people have mentioned using a Cray to crack passwords. From what I have read, and from benchmark results, the Cray is not a very fast CPU for non-vector operations. So, unless the password encryption can be vectorized, the Cray is not likely to be very fast at doing it. Now maybe one of those Amdahl systems... Someone else posted that the Unix salt was really restricted to 400 values. I checked my (4.3BSD) systems. Out of 774 unique encryptions there were 702 unique salts. (Many times the same password is used on different systems so we copy it, salt and all.) I assume that the 400 salt bug either applies to some other version or is untrue. A larger salt would be a good idea though. Multi gigabyte, even terabyte storage is available today so a precomputed password dictionary, indexed for fast access, becomes more and more practical. Hiding the real passwords in a second copy of the /etc/password file that can only be read by root sounds easy to implement and should protect against private copies of crypt running. It also limits legitimate use of the password, the "gone" program for example. You also return to the situation the Unix password system was designed to avoid. If someone EVER gets root access, even if only read access, then they can mail the password file to themselvs. And how about that extra root dump you keep handy for booting systems? Is it locked up tight? My point is that this requires new procedures to fully implement it. Of course, even if it leaks, security is no worse than with publicly readable passwords. Me? I am fighting to get our users to use passwords, preferably something different from their login name. Jerry Aguirre
jwm@stdc.jhuapl.edu (Jim Meritt) (11/15/88)
In article <2328@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: }It's well known how to have a secure system. Don't have any lines into the }system. In a vault, with an armed guard, with the power off. After checking the manufacturers and software suppliers. And examining all the source for trojans. With totally cleared users and maintenance personnel. Maybe embedded in concrete. Alarmed. Heck, you can't keep people away from nuclear wastes and you thing something NEAT can be totally secure!?!?!?! Disclaimer: "It's mine! All mine!!!" - D. Duck
henry@utzoo.uucp (Henry Spencer) (11/16/88)
In article <2432@aplcomm.jhuapl.edu> jwm@aplvax.UUCP (Jim Meritt) writes: >In a vault, with an armed guard, with the power off. >After checking the manufacturers and software suppliers. >And examining all the source for trojans. >With totally cleared users and maintenance personnel. As Dennis Mumaugh has pointed out, a cracker with sufficient resources will simply bribe one of your staff. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dwm@ihlpf.ATT.COM (Meeks) (11/18/88)
You can't stop people from coming up with ways to break into your information system. Not as long as more than one person has access. Two things I would suggest are: A VERY GOOD BACKUP SYSTEM, saving fulls for what may seem a very long time, like forever. Doing lot's of different level incrementals and then maybe a few project specific snapshots. Take pictures of your /, /usr, and /tmp. These pictures will include time stamps, ownership, size and checksum. Okay, how does this help? You can with the picture information monitor what is going on in important areas of your system and look for problems. When recovering, the several levels of incremental and project snapshots will come in handy if the virus is a particular nasty one. I would suggest you automate the picture taking and save your database in a safe place, remember it too could come under attack. Making a system secure at the risk of making it difficult to share information is poor use of time. It only costs those who use the system as a tool to get real work done. Security is all our responsibility and not to be taken lightly. Each of us need to use good passwords, terminal lock programs, and not put passwords on post-its which we then place on our terminals. Daniel W. Meeks, ...[att!]ihlpf!dwm, dwm@ihlpf.att.com --> These are my thoughts and not necessarily shared by my employer. <--
allbery@ncoast.UUCP (Brandon S. Allbery) (11/20/88)
As quoted from <556@suadb.UUCP> by anders@suadb.UUCP (Anders Bj|rnerstedt): +--------------- | 6. A less blunt use of the set-user-id mechanism. | Sendmail apparently needs to do rights amplification, | but I dont see why it needs superuser rights. The uucp +--------------- On networked systems, sendmail has to be able to listen on the SMTP network port -- which requires superuser permissions. +--------------- | 7. It should be *possible* to physically write lock filesystems | including the root file system. The disk write lock could +--------------- SunOS 4.x mounts / read-only, doesn't it? +--------------- | systems marked "secure". The kernel (which would itself be | placed in a secure filesystem) would only allow writes to | a secure filesystem if a physical togle was in the "open" | position. Normally the togle would be in the closed position. +--------------- Interesting thought. However, I think it should be reserved for heavy-duty security; such an arrangement, for example, would mean the end of ncoast. (Most of the maintenance on ncoast is done over the modem.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.