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@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 +--------------------------------------
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.)
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
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
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/11/88)
In article <2182@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >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 decryption is possible only >through administrator error. It would be a great service to the community if specifications for this feature were posted or at least sent to developers who want to enable a similar feature on their (typically BSD-based) systems. For example, what is the shadow file called, what is its format, what sort of stuff is left in the password field in /etc/passwd, what facilities are there to validate a password against the shadow encrypted password file?
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
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
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
peter@ficc.uu.net (Peter da Silva) (11/13/88)
In article <8861@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > It would be a great service to the community if specifications for > this feature were posted or at least sent to developers who want > to enable a similar feature on their (typically BSD-based) systems. Based on the SV/386 version: > For example, what is the shadow file called /etc/shadow > , what is its format, Same as passwd, but only the username and password are filled in. > what sort of stuff is left in the password field in /etc/passwd, The letter 'x'. > what facilities are there to validate a password against the > shadow encrypted password file? I believe you have to be root to do this. There don't seem to be any facilities to do this for user programs, but I haven't read all the docs. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/15/88)
From: peter honeyman <honey@mailrus.cc.umich.edu> Date: 10 Nov 88 05:40:29 GMT Sender: usenet@mailrus.cc.umich.edu 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 In *core* on a Cray :-) (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Careful with that VAX Eugene!
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. <--
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/18/88)
? From: Peter da Silva <peter@ficc.uu.net> ? > For example, what is the shadow file called ? /etc/shadow My first reaction is not to put it in /etc, or hide it with a dot, or call it something weird, but that doesn't really accomplish much. ? > , what is its format, ? Same as passwd, but only the username and password are filled in. Why not fill it all in? ? > what sort of stuff is left in the password field in /etc/passwd, ? The letter 'x'. Here I disagree. It just announces the existence of the shadow file. A better thing to do would be encrypt the password as usual, *and then select a random salt* to replace the salt it was encrypted with. That way, naive people can crack away to no avail. I note that you are reporting things the way they *are*; my comments are IMHO the way they *should be*. ? Peter da Silva `-_-' Ferranti International Controls Corporation ? "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter ? Disclaimer: My typos are my own damn business. peter@ficc.uu.net (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Works -- Breakfast of Champions!
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/18/88)
In article <17575@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >A better thing to do would be encrypt the password as usual, *and then >select a random salt* to replace the salt it was encrypted with. That >way, naive people can crack away to no avail. No, that's not right since it doesn't block the "snarf /etc/passwd and run trial passwords against it" approach. If you want to leave encrypted passwords in /etc/passwd please make sure that (a) they are encryptions of random gobbledook and (b) the verification scheme never accepts a match against /etc/passwd as validating a user under any circumstances. (The scheme Mumaugh described did.)
w-colinp@microsoft.UUCP (Colin Plumb) (11/18/88)
In article <17575@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >? /etc/shadow > >My first reaction is not to put it in /etc, or hide it with a dot, or >call it something weird, but that doesn't really accomplish much. This is correct. *Real* security assumes the attacker knows as much as you do about the system. >? Same as passwd, but only the username and password are filled in. >Why not fill it all in? Because the other stuff is supposed to be world-readable - why bother keeping a copy which nobody needs? And the update synchronisation problems... >? > what sort of stuff is left in the password field in /etc/passwd, > >? The letter 'x'. > >Here I disagree. It just announces the existence of the shadow file. >A better thing to do would be encrypt the password as usual, *and then >select a random salt* to replace the salt it was encrypted with. That >way, naive people can crack away to no avail. I repeat: security assumes the attacker knows as much as you do. This is what's fundamentally right about the existing Unix password system. The *only* piece of information it's possible to extract from the system is whether user "foo" has password "bar". This applies no matter what knowledge of privelege level you have. Putting extra barriers in the face of the naive doesn't increase your real security one bit, and does distract you from your main goal. Indeed, this is why I'm against the idea of a shadow password file. It is physically possible to get at it, and so only discourages weak attacks which probably wouldn't succeed anyway, providing a false sense of security. Getting a copy of /etc/shadow may involve breaking into the computer room and stealing some backup tapes, but more likely a good Unix hack knows half a dozen ways to get a copy of a root-readable-only file. A bug in some setuid-root utility not vhecking to see if the ruid has the proper permissions before printing/mailing/uucp-ing/whatever the file? As it stands, the only thing that's worth getting at that way are the system sources, which lots of people have already. What *I* want is the VAX to run them on - or the next-best thing, a password on somebody else's VAX. If we keep the password function sufficiently simple that it can be computed in a reasonable amount of time (1/4 sec?) on an 11/750 or similar wimpy machine, assuming I have a Sun/4 (10 times as fast?) and a week or two to spend at it, the only way to stop me from guessing passwords is to expand the search space to more than 4*60*60*24*15*10 = 51840000 passwords. This is more than the number of 5-letter lower-case passwords, although significanly less than the number of 6-letter ones. If you add mixed case and whatnot, you have more possible passwords than any brute-force attempt can hope to attack. A more selective search must come up with a list of "probable" passwords. If you make passwords fit some strange pattern that bears no resemblance to anything else (as I suggested in my last posting, strip off the first and last characters, and require the remaining ones to contain an upper-case letter, a lower-case letter, and a digit), neither the people picking the passwords or the cracker has anything the password "should" resemble, so there's no word list a cracker can use, and very little data to build one from. Remember: on a Unix system, most routes to a root shell don't involve knowing the root password. So don't assume someone with root priveleges doesn't need to crack passwords. Make it hard even for root. (P.S. Personally, I'm not keen on passwords. Hooray for Der Mouse! But there's no point in having the annoyances, and not the advantages, of a properly done system.) -- -Colin (microsof!w-colinp@sun.com)
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>.
chris@mimsy.UUCP (Chris Torek) (11/20/88)
In article <31@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes: >I repeat: security assumes the attacker knows as much as you do. This >is what's fundamentally right about the existing Unix password system. >The *only* piece of information it's possible to extract from the system >is whether user "foo" has password "bar". This applies no matter what >knowledge of privelege level you have. `Security' is not really an absolute. The security of a system can only be estimated, and even then, only with some assumptions in mind. While there is substantial merit in the existing scheme (which does not assume that `unreadable' shadow files are in fact unreadable), there is also considerable merit in multiple barriers. >Putting extra barriers in the face of the naive doesn't increase your real >security one bit, and does distract you from your main goal. Define `your real security'. We have people who more or less idly try to log in (`user fred, password fred; user mike, password mike; oh well, so much for that'), people who make a slightly more determined effort (get a listing of actual login names and full names, perhaps by reading over professors' shoulders, and work from that: these people usually find it simpler instead to get *paid* to use the machine: i.e., become an RA or TA), and, rarely, a real attack from someone who knows something about Unix systems. We already have adequate protection against the first two types---not perfect, but adequate; we would like to have protection against the third. Shadow password files are a step in that direction. They may not keep everyone out, but they are likely to help. Nothing we do will keep out the NSA, or even the Marines [hi rab! :-) ], but that is not our objective. Our objective is to keep out the `average' attacker, whose ability to decrypt Unix-style encrypted passwords is on the rise. >If we keep the password function sufficiently simple that it can be >computed in a reasonable amount of time (1/4 sec?) on an 11/750 or >similar wimpy machine, assuming I have a Sun/4 (10 times as fast?) and >a week or two to spend at it. . . . Would you like to suggest such a function? Software DES is nowhere near that hard. Besides, you may have access to a network of hundreds of machines hundreds of times faster, and more than just a week or two to spend. This is where shadow files, password aging, multi-level (`ring') schemes, ACLs, and (eventually) all the rest of the high level security schemes come in. They all have some cost; the proper design of a security system selects the one with the most value for the least cost. The value of shadow files is low, but so is the cost; it is (now, suddenly) seen as within our budget. (Actually, we are thinking of using the MIT Kerberos stuff instead, here. It has a somewhat higher cost, but has more value too.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/23/88)
>From Doug Gwyn ? In article <17575@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: ? >A better thing to do would be encrypt the password as usual, *and then ? >select a random salt* to replace the salt it was encrypted with. That ? >way, naive people can crack away to no avail. ? No, that's not right since it doesn't block the "snarf /etc/passwd ? and run trial passwords against it" approach. If you want to leave ? encrypted passwords in /etc/passwd please make sure that (a) they ? are encryptions of random gobbledook and (b) the verification ? scheme never accepts a match against /etc/passwd as validating a ? user under any circumstances. (The scheme Mumaugh described did.) My suggesting the resalting technique was an attempt to disguise the encryption. As it turns out, since the encryption algorithm is completely dense, I have unwittingly provided a target. I accept your (a) (altho why bother to encrypt at all?), and never suggested (b). (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Worms -- Breakfast of Champions!