[3765] in bugtraq
Weakness in some linux versions of adduser.
daemon@ATHENA.MIT.EDU (Dan Merillat)
Mon Dec 9 00:33:39 1996
Date: Sun, 8 Dec 1996 23:39:56 -0500
Reply-To: Dan Merillat <Dan@Merillat.org>
From: Dan Merillat <Dan@Merillat.org>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
Aside from glaring buffer overflows (which are unimportant, as only
administration should have access to the adduser script) I do notice
an interesting statistical weakness in adduser... namely, the salt generation.
The following table is a list of how often the same salt key showed up in
different passwords. The fields are number of occurances : times it showed
up. I.E. for the first there were 12 aa and 12 bb keys.
12: 2
11: 1
10: 3
9: 9
8: 11
7: 29
6: 32
5: 50
4: 44
3: 38
2: 48
1: 417
This seems quite odd... The reason there are 417 unique salt keys is that
We rewrote the salt generation to generate true 12 bit salts... I believe the
stock version on sunsite only generated 8 significant bits of salts.
Now over 1700 passwords, with 12 bits of salt keys, we should be seeing
mostly unique salt keys.
Now, the larger the site you have, the bigger a security hole this becomes.
Because of the way crack works (sort by crypt and do compares on as many as
you can get at once) you speed up a brute-force attack on your password file
by a factor of 16... or more if your salts have even less significant bits.
The routine in question (adduser used in slackware and on sunsite in
/system/Admin/accounts/adduser looks like this:
{
time(&tm);
salt[0] = (tm & 0x0f) + 'A';
salt[1] = ((tm & 0xf0) >> 4) + 'a';
}
This has got to be the _WORST_ random generator I have seen in a long time.
Over 10000 salts generated:
60: 1 48: 4 41: 19 34: 7 27: 3
54: 1 47: 5 40: 14 33: 10 26: 4
53: 2 46: 8 39: 20 32: 7 25: 1
52: 3 45: 13 38: 20 31: 9
51: 2 44: 10 37: 13 30: 9
50: 5 43: 20 36: 10 29: 5
49: 6 42: 9 35: 12 28: 3
npasswd_boulder (as distributed via RedHat) has much better statistics:
10: 1
9: 5
8: 17
7: 35
6: 107
5: 299
4: 562
3: 830
2: 950
1: 789
(this is for 10000 randomly generated salts)
The random generator is fine, but for a salt key they are only using the
lowest 7 bits, then checking if it is alphanumeric... which is very broken.
The proper way is to generate 12 bits of random data, then split into 2 6 bit
parts, then use those 6 bits as an index into an array of acceptable chars.
Comments? I would like to see some statistics from some larger sites...
I just used cut and uniq -c on the password file to generate these, if someone
wants to do some better statistical analysis I would apprecitate their
findings.
Credit for the find goes to Eric Shaw <Eric@ao.net>
