How to stop future viruses.
Dennis L. Mumaugh
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!d...@arpa.att.com
Greg
>In article <16...@agate.BERKELEY.EDU> gr...@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
>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
John F. Haugh II
| 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.
|
|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: j...@rpp386.Dallas.TX.US | "Just say `No, Honey'"
UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
John B. Nagle
>In article <21...@cuuxb.ATT.COM> d...@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
peter honeyman
>... 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
Richard A. O'Keefe
>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...
Steven M. Bellovin
> 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.)
Dennis L. Mumaugh
> 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.
Jeff Siegal
>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
Doug Gwyn
>security aspects except to mention that System V Release 3.2 does
>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?
peter honeyman
>In article <7...@mailrus.cc.umich.edu>, ho...@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 Templeton
the time, I think.
The idea was that non-ecrypted passwords in an unreadable file is no
kind of password security, although it's exactly the kind of security
that GCOS has.
If you use this method, than any problem which allows mere *read* access
to disks is enough to get complete, often undetectable, access to the system.
For example, just physical access to disk packs or backup tapes is enough.
So when they made the Unix password file, as I understand it, they said,
"We have to assume people will get at the password entries, so let's put
all or security into encryption."
With hindsight, it seems a combination is in order, but the philosophy
that you should assume that any sophisticated cracker will get to read
them still should apply.
--
Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
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
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: and...@sisu.se OR anders%sis...@uunet.uu.net
UUCP:{uunet,mcvax,cernvax}!enea!sics!sisus!anders.
Dennis L. Mumaugh
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
>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?
The documentation is scattered in the Release Notes for System V
Release 3.2. Of course they don't have a page shadow(4) but:
The file is /etc/shadow and is owned by root and mode 400.
It contains one line per login. Fields are separated by colons:
username \- users login name
password \- A 13 character encrypted password or a lock string to
indicater the login is not accessible
lastchanged \- number of days since January 1, 1970 that the password
has been modified
min \- the number of days required between password changes
max \- the maximum number of days the password is valid.
Routines to work with /etc/shadow:
#include <shadow.h>
struct spwd *getspent();
struct spwd *getspnam(char * name);
void setspent();
void endspent();
struct spwd *fgetspent(FILE *fp);
int putspent(struct spwd *p,FILE *fp);
Programs allied with this are
pwconv \- install and/or update /etc/shadow with information
from /etc/passwd
pwunconv \- restore /etc/password from /etc/shadown
Programs like login, su and passwd work with either /etc/passwd
ONLY or with the added /etc/shadow. If there is no entry in
/etc/shadow we accept the /etc/passwd as gospel [in case someone
forgot to run /usr/lib/pwconv after adding a user.]
Also /usr/include/shadow.h:
struct spwd {
char *sp_namp; /* users login name */
char *sp_pwdp; /* encrypted password */
long sp_lstchg; /* number of days since January 1, 1970
that the password has been modified */
int sp_max; /* the number of days required between password changes */
int sp_min; /* the maximum number of days the password is valid. */
}
#define SHADOW "/etc/shadow"
ATT doesn't provide any of the functions or the header file as
part of its product. It is in the source but not the binary.
Thus developers who need the routines must contact their ATT
person [not me!] to obtain the shadow password security library
Jerry Aguirre
>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
Paul M. Aoki
Hmm. I just pawed over the password file on ernie.berkeley.edu
[ that's right, the place the worm was transmitting its location to ... ]
and found 630 salts for 671 accounts with passwords. Some of those
passwords have been there for an awfully long time.
Where did you get this information?
----------------
Paul M. Aoki
CS Division, Dept. of EECS // UCB // Berkeley, CA 94720 (415) 642-1863
ao...@postgres.Berkeley.EDU ...!ucbvax!aoki
Doug Gwyn
>Release 3.2.
Thanks for posting the information. It is sites that DON'T HAVE
SVR3.2 that are most in need of this information.
>If there is no entry in
>/etc/shadow we accept the /etc/passwd as gospel [in case someone
>forgot to run /usr/lib/pwconv after adding a user.]
That seems like a mistake. Far better to detect this omission
when the new user first tries to log in than to gradually accumulate
security holes.
It also seems that the following are missing:
"pwvalid" utility (necessarily privileged) to SLOWLY
check a (user,password) pair for validity. Since it is
insecure to pass this information as command-line
arguments, they should be read from standard input
(typically via a pipe connection). Obviously the exit
status would be 0 if and only if the pair checks out ok.
(The temptation to also log failures should be resisted!)
A two-second delay should be acceptably slow.
"int pwvalid(const char *user, const char *password)"
C library function that simply opens a pipe to the above
utility and returns true only when the arguments
constitute a valid pair.
In the above, probably it would be safest to use the encrypted form
of a trial password instead of plaintext. It bothers me that some
network protocols send unencrypted passwords over the network.
All password-checking programs should use these interfaces to validate
passwords. ("passwd" can use them for part of its job, but it also
has to update the shadow file. So far as I know no other program
needs to write (encrypted) passwords in such that it couldn't use
"passwd" to do this for it.)
Jeff Siegal
>In article <10...@eddie.MIT.EDU> j...@fenchurch.UUCP (Jeff Siegal) writes:
>Hmm. I just [...] found 630 salts for 671 accounts [...].
Yes, it is pretty clear now that my claim is wrong.
>Where did you get this information?
I was told this a while ago--I don't remember by whom. Before posting
the information, I did check the source code but I did not think very
hard about what I saw.
After looking again and thinking a bit, I see now why it isn't true.
Jeff Siegal
Peter da Silva
> 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. pe...@ficc.uu.net
MFHorn
> 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.
On one of our machines here, I can generate about 50 encryptions
per second. That's about 500 seconds (8 minutes) to encrypt
/usr/dict/words. I could probably throw together some 'rsh'
command lines to make some of our big Vaxen, MVs, Apollo and
DEC workstations, etc., do the part of the work, and I'm encrypting
the dictionary in under a minute.
Compare this to the time it would take to grep through N Meg of
pre-encrypted data, and you'll see they're very close (and both
negligible).
> The major point is that properly prepared one CAN crack passwords
> in less than an hour given adequate resources.
Less than a minute.
Andy Rosen | aro...@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031 | ulowell!arosen | learned how to make it
Lowell, Ma 01854 | | talk" -Thunder Road
RD in '88 - The way it should've been
MFHorn
> It also seems that the following are missing:
>
> "pwvalid" utility (necessarily privileged) to SLOWLY
> check a (user,password) pair for validity.
>
> C library function that simply opens a pipe to the above
> utility and returns true only when the arguments
> constitute a valid pair.
This is similar (maybe identical) to the approach I would take,
where the idea is to turn off world read-access to /etc/passwd,
but still allow users to get other information from /etc/passwd.
1: chmod 400 /etc/passwd
2: Write a server (passwdd) to accept connections from clients
who request the password entry for a given user
3: Re-write getpw{ent,uid,nam} to connect to the client
4: Re-compile everything that uses getpw{ent,uid,nam}
With this, you can very easily monitor all types of access to
/etc/passwd, and restrict access to it, if desired.
Passwdd should give the client all fields of the password entry
except the encrypted password unless it is the entry of the
requesting user or the user is superuser. Now, the only way
to test what a user's password is, is to try to login with it.
The result allows users to write their own programs that do
validation by login password without breaking programs like
finger, csh (~ expansion), ls (-l), whoami, and any others
that look at /etc/passwd.
Authenticating the client is the next problem...
Hans H. Huebner
developers interested in a library which confirms to the AT&T shadow password
file scheme as described by Dennis, send me a short note. I have hacked
together what Dennis specified in his earlier note, but I can't guarantee
that it works *exactly* the same way AT&T does it.
If there's enough interest, I'll post the stuff to rsalz and alt.sources as
soon as I have the manual pages finished.
Hans
P.S.: Please reply to pe...@garp.mit.edu if you're in the USA - Thanks
--
Hans H. Huebner, netmbx | PSIMail: PSI%026245300043100::PENGO
Woerther Str. 36 | DOMAIN: pe...@tmpmbx.UUCP
D-1000 Berlin 20, W.Germany | Bang: ..!{pyramid,unido}!tmpmbx!pengo
Phone: (+49 30) 882 54 29 | BITNET: huebner@db0tui6
Mark F. Proudman
/etc/shadow related utilities and/or library calls? If these are not
available through the Toolchest, they should be - the market is there.
Mark Proudman uunet!attcan!sobeco!mfp
(514) 878 9090
"It is agreed that the ice is thin here" - K&R.
Guy Harris
> who request the password entry for a given user
>3: Re-write getpw{ent,uid,nam} to connect to the client
>4: Re-compile everything that uses getpw{ent,uid,nam}
Sounds like you've just invented Yellow Pages....
SunOS 4.0 has, in its "C2 secure" mode, a shadow password file, as well
as an RPC-based "password validation" server. The latter is the way you
let non-privileged programs match passwords; I suspect you send the
encrypted password over the wire and ask it "does this match the
encrypted password for user 'x'?" This is a similar approach to the
"privileged password validation" utility Doug suggested.
peter honeyman
Root Boy Jim
? In the above, probably it would be safest to use the encrypted form
? of a trial password instead of plaintext. It bothers me that some
? network protocols send unencrypted passwords over the network.
Perhaps I don't understand the problem fully, but it seems to me that
I could just write a client that sends, say, the login name and the
encrypted password (which I got from reading the password file) over
the net and masquerade as a legitimate host. Unless you send the plaintext
password over the net, you preclude the server from checking the validity
itself. And you force all encryption algorithms to be the same.
(Root Boy) Jim Cottrell (301) 975-5688
<r...@nav.icst.nbs.gov> or <r...@icst-cmr.arpa>
Crackers and Works -- Breakfast of Champions!
Meeks
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, d...@ihlpf.att.com
--> These are my thoughts and not necessarily shared by my employer. <--
Root Boy Jim
? > 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. pe...@ficc.uu.net
Chris Torek
>>In the above, probably it would be safest to use the encrypted form
In article <17...@adm.BRL.MIL> r...@nav.icst.nbs.gov (Root Boy Jim) writes:
>Perhaps I don't understand the problem fully, but it seems to me that
>I could just write a client that sends, say, the login name and the
>encrypted password (which I got from reading the password file) over
>the net and masquerade as a legitimate host.
The trick is to encrypt the trial password with a different key. The
authentication server sends the client a new key, which has been
encrypted with the client's private key; the client decrypts the string
using its private key to obtain the temporary key. The client then
uses the temporary key to encrypt the trial password, and sends that to
the server; the server decrypts using the temporary key, encrypts using
the user's private key, and compares. If those match, the
authentication server believes that the client is acting on behalf of
the user.
(Clear? :-) )
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Doug Gwyn
!? In the above, probably it would be safest to use the encrypted form
!? of a trial password instead of plaintext. It bothers me that some
!? network protocols send unencrypted passwords over the network.
!Perhaps I don't understand the problem fully, but it seems to me that
!I could just write a client that sends, say, the login name and the
!encrypted password (which I got from reading the password file) over
!the net and masquerade as a legitimate host. Unless you send the plaintext
!password over the net, you preclude the server from checking the validity
!itself. And you force all encryption algorithms to be the same.
Yes, never mind the suggestion about encryption. It doesn't add enough
security to be worth the additional hassle. Genuinely secure network
verification of users requires FAR more work.
If someone wants to implement user/password verification interfaces
along the lines that I suggested, don't bother with encryption outside
the implementation itself.
Doug Gwyn
>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.)
The Beach Bum
> Hello,
>
> developers interested in a library which confirms to the AT&T shadow password
> file scheme as described by Dennis, send me a short note. I have hacked
> together what Dennis specified in his earlier note, but I can't guarantee
> that it works *exactly* the same way AT&T does it.
>
> If there's enough interest, I'll post the stuff to rsalz and alt.sources as
> soon as I have the manual pages finished.
I got impatient. Attached is my clone which I'll be including in the soon
to be released login clone. The routines were all very simple, I didn't
see any point in holding out ...
This was all written straight off of Dennis' article. You may do with it
as you please. So much for security by obscurity [ Thanks James ... ]
It is as simple minded as possible, your suggestions, as always, are
more than welcome.
- John.
--
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# shadow.c
# shadow.h
# This archive created: Fri Nov 18 00:07:19 1988
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'shadow.c'
then
echo shar: "will not over-write existing file 'shadow.c'"
else
cat << \SHAR_EOF > 'shadow.c'
#include "shadow.h"
#include <stdio.h>
#include <string.h>
static FILE *shadow;
void setspent ()
{
if (shadow)
rewind (shadow);
else
shadow = fopen (SHADOW, "r");
}
void endspent ()
{
if (shadow)
fclose (shadow);
}
struct spwd *fgetspent (fp)
FILE *fp;
{
static struct spwd spwd;
static char name[32];
static char pass[32];
char buf[BUFSIZ];
char *cp;
int atoi ();
long atol ();
if (! fp)
return (0);
if (fgets (buf, BUFSIZ, fp) == (char *) 0)
return (0);
if ((cp = strtok (buf, ":")) && *cp)
strcpy (name, cp);
else
return (0);
if ((cp = strtok ((char *) 0, ":")) && *cp)
strcpy (pass, cp);
else
return (0);
if ((cp = strtok ((char *) 0, ":")) && *cp)
spwd.sp_lstchg = atol (cp);
else
return (0);
if ((cp = strtok ((char *) 0, ":")) && *cp)
spwd.sp_min = atoi (cp);
else
return (0);
if ((cp = strtok ((char *) 0, ":")) && *cp)
spwd.sp_max = atoi (cp);
else
return (0);
spwd.sp_namp = name;
spwd.sp_pwdp = pass;
return (&spwd);
}
struct spwd *getspent ()
{
return (fgetspent (shadow));
}
struct spwd *getspnam (name)
char *name;
{
struct spwd *spwd;
setspent ();
while ((spwd = getspent ()) != (struct spwd *) 0) {
if (strcmp (name, spwd->sp_namp) == 0)
return (spwd);
}
return (0);
}
int putspent (spwd, fp)
struct spwd *spwd;
FILE *fp;
{
if (! fp)
return (0);
return (fprintf (fp, "%s:%s:%ld:%d:%d\n",
spwd->sp_namp, spwd->sp_pwdp,
spwd->sp_lstchg, spwd->sp_min, spwd->sp_max) > 0);
}
SHAR_EOF
fi
if test -f 'shadow.h'
then
echo shar: "will not over-write existing file 'shadow.h'"
else
cat << \SHAR_EOF > 'shadow.h'
/*
* This information is not derived from AT&T licensed sources. Posted
* to the USENET 11/88.
*/
/*
* Shadow password security file structure.
*/
struct spwd {
char *sp_namp; /* login name */
char *sp_pwdp; /* encrypted password */
long sp_lstchg; /* date of last change */
int sp_max; /* maximum number of days between changes */
int sp_min; /* minimum number of days between changes */
};
/*
* Shadow password security file functions.
*/
struct spwd *getspent ();
struct spwd *getspnam ();
void setspent ();
void endspent ();
struct spwd *fgetspent ();
int putspent ();
#define SHADOW "/etc/shadow"
SHAR_EOF
fi
exit 0
# End of shell archive
--
John F. Haugh II +----------Quote of the Week:----------
VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north-
InterNet: j...@rpp386.Dallas.TX.US | ern California." -- Henry Spencer
UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
Richard A. O'Keefe
>
>Perhaps I don't understand the problem fully, but it seems to me that
>I could just write a client that sends, say, the login name and the
>encrypted password (which I got from reading the password file) over
>the net and masquerade as a legitimate host.
Simple answer: use two encryption functions. A password PP then goes
through two stages:
TP := encrypt(PP) for transmission to:(H) -- at calling site
FP := encrypt(TP) for inclusion in:(/etc/passwd) -- at site H
The password which is sent of the net in this scheme is TP, which is
_not_ stored in /etc/passwd; _that_ one is FP. TP would be stored
nowhere. It would be vulnerable to a /dev/kmem watcher, but there is
a way around that: when the caller says "I want to send a password",
site H sends back a one-time encryption function. The next time PP is
sent to H, TP may be completely different.
Dave Brower
>
>? In the above, probably it would be safest to use the encrypted form
>? of a trial password instead of plaintext. It bothers me that some
>? network protocols send unencrypted passwords over the network.
>
>Perhaps I don't understand the problem fully, but it seems to me that
>I could just write a client that sends, say, the login name and the
>encrypted password (which I got from reading the password file) over
>the net and masquerade as a legitimate host. Unless you send the plaintext
>password over the net, you preclude the server from checking the validity
>itself. And you force all encryption algorithms to be the same.
The answer to a large number of these authentication problems is alleged
to be the one way public key encrytption available from RSA. Does
anyone know some of the salient facts about this approach?
* How "secure" is the encryption to common attacks,
including brute force?
* What does it really cost to license from RSA, and
what do you get for your license.
* Is anyone actually using it in anything?
-dB
--
"It if was easy, we'd hire people cheaper than you to do it"
{sun,mtxinu,hoptoad}!rtech!gonzo!daveb da...@gonzo.uucp
Brandon S. Allbery
+---------------
| 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!all...@hal.cwru.edu
allb...@skybridge.sdi.cwru.edu <ALSO> all...@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>.
Colin Plumb
>
>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-co...@sun.com)
Chris Torek
>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.)
Root Boy Jim
? In article <17...@adm.BRL.MIL> r...@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
<r...@nav.icst.nbs.gov> or <r...@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!
Tim Bray
> 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
In any reasonably large organization, I feel much more nervous about people
stealing my password by looking over my shoulder rather than people crawling
through my network. Having once been sysadmin and having to type the root
password in an environment with tons of occasionally bored engineers hanging
around made me *real* nervous. So: pick a password that's >6 chars and *you
can type it fast*. For a touch-typist, this means alternating left and right
hand strokes. Obviously it shouln't be in /usr/dict/words, but there's lots
of words like that...
Tim Bray, New OED Project, U of Waterloo, Ontario
Larry Wall
: In any reasonably large organization, I feel much more nervous about people
: stealing my password by looking over my shoulder rather than people crawling
: through my network. Having once been sysadmin and having to type the root
: password in an environment with tons of occasionally bored engineers hanging
: around made me *real* nervous. So: pick a password that's >6 chars and *you
: can type it fast*. For a touch-typist, this means alternating left and right
: hand strokes. Obviously it shouln't be in /usr/dict/words, but there's lots
: of words like that...
One of my favorite passwords used to be "kandle" for that very reason.
(Oops, I guess I can't use that one any more...)
Another trick (if there's only one or two looking over your shoulder) is
to look at them, and as soon as they look at you, type your password. Again,
touch typing is pretty much a requirement.
What's embarrassing is to type your password into the wrong window...
Larry Wall
lw...@jpl-devvax.jpl.nasa.gov
Dennis L. Mumaugh
I got impatient. Attached is my clone which I'll be including in the soon
to be released login clone. The routines were all very simple, I didn't
see any point in holding out ...
This was all written straight off of Dennis' article. You may do with it
as you please. So much for security by obscurity [ Thanks James ... ]
It is as simple minded as possible, your suggestions, as always, are
more than welcome.
- John.
A colleague contacted me and expressed concern that the
implementation of /etc/shadow might not exactly reflect that of
AT&T. I checked John's version of shadow.h and discovered a
small difference over the "Official" shadow.h. For those with
sizeof(int) == sizeof(long) there is no problem but "All's the
world is not a VAX [or 3B2]." Here is the changed shadow.h:
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..
if test -f 'shadow.h'
then
echo shar: "will not over-write existing file 'shadow.h'"
else
cat << \SHAR_EOF > 'shadow.h'
/*
* This information is not derived from AT&T licensed sources. Posted
* to the USENET 11/88.
*/
/*
* Shadow password security file structure.
*/
struct spwd {
char *sp_namp; /* login name */
char *sp_pwdp; /* encrypted password */
long sp_lstchg; /* date of last change */
long sp_max; /* maximum number of days between changes */
long sp_min; /* minimum number of days between changes */
};
/*
* Shadow password security file functions.
*/
struct spwd *getspent ();
struct spwd *getspnam ();
void setspent ();
void endspent ();
struct spwd *fgetspent ();
int putspent ();
#define SHADOW "/etc/shadow"
SHAR_EOF
fi
echo "End of shell archive shadow.h"
exit 0
# End of shell archive
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!d...@arpa.att.com