toor@wipux2.wifo.uni-mannheim.de said:

> 	   I use a '*' to lock accounts like 'daemon','bin' and I had
> 	   also locked 'guest' like this. Somebody just pressed 'return'
> 	   when asked for Password and was let in.

To which "Charles M. Hannum" <mycroft@gnu.ai.mit.edu> replied:

> I recall an old bug luck this in an early version of the non-US
> `securedist' crypt(3), but I thought it was fixed a long time ago.

Someone here discovered this problem in David Burren's FreeSec 0.2 package a
while back.  So I changed our "*" passwords to "xx" and made a note to check
out whether the bug still existed in FreeSec 1.0 when I upgraded to it (which
by that time had already been released).

Unfortunately, I forgot about the problem until seeing this message :-(

Now, on checking my libcrypt sources I find I *am* running 1.0 (I must have
upgraded in my sleep sometime :-), and that the problem still exists.

In fact, the problem occurs for any single character password.  The first two
characters of the encrypted password from the passwd file are passed by login
to crypt() as the salt.  Crypt() copies these directly to the begining of the
string that it will return.  For a single character passwd file entry, this
results in the 2nd character of the string returned by crypt being '\0', so the
comparison done by login between the password from the passwd file and the
return value of crypt() always succeeds, regardless of what the user typed.

I'm not sure how the "official" non-exportable crypt() solves this, but I would
guess that it either returns an empty string when given a single character
salt, or perhaps pads out the single character salt with a non-null character.

I'm not sure whether David has already fixed this in his FreeSec package, or if
not, whether he is going to be able to release a fixed version, since I gather
that export of cryptographic software from Australia may come under similar
laws to those of the US.

Duncan

------------------------------------------------------------------------------