From owner-freebsd-security Tue Feb 18 07:31:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA10134 for security-outgoing; Tue, 18 Feb 1997 07:31:56 -0800 (PST) Received: from grackle.grondar.za (iIl2mAu7gTCaBGssAycMeZeH8TKFSBtm@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA10118 for ; Tue, 18 Feb 1997 07:31:46 -0800 (PST) Received: from grackle.grondar.za (ujzeR1ZvgUfJ3nOmNG3nRnRUZawKjEuB@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id RAA07047; Tue, 18 Feb 1997 17:31:04 +0200 (SAT) Message-Id: <199702181531.RAA07047@grackle.grondar.za> To: Mikael Karpberg cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Date: Tue, 18 Feb 1997 17:31:01 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > I must say, I have NO idea how you mean this. Either you are very confused, > or I am very confused. One of the two, and I don't know which. :-) > > First of all, so what is crypt returns something predictable for a certain > input? Crypt's strength might be that you can't get the output you want by > tweaking th input, BUT... what has that got to do with it? The point is > that even if you know you can get crypt to return "************", it's > really not going to do you any good, is it? If you could, by just entering > a certain password, make crypt produce that string (and you couldn't. You > would need to also set the salt, etc, meaning you have to write a c program > to do it. And why bother comparing strings, then, when you can just succeed?) > it would do you no good at all, since login (or whatever program you use > for trying to hack root) would compare the output against the password > in the /etc/master.passwd file, and that will never _be_ "***********", so > you will never get a match anyway, and failing a match, login will be refused . > Where did I err in thinking this (if I did)? OK - here's the attack: Our luser has fouled up his system a bit (this is a prerequisite), so that he has passwords that are your default *************. The attacker notices the foul-up, guesses there are ********** passwords, and trys to get in. He should be able to get login to execute crypt("***************", "rubbish password typed at passwd:prompt") to return "***************", IOW the same "crypted" password as the passwd file. This lets him in. If this happens to th root account, he is in. > Second, after some "research" (actually reading the manpage for crypt) > I found this in crypt's manpage: > "The function crypt() returns a pointer to the encrypted value on success > and NULL on failure." > > Note: Or NULL on failure. I didn't think it could return that. That changes > things; it _is_ TRT to return NULL if you don't find the lib for a > choosen encryption. So that should be the end of that. :-) Fair enough. > How do you crash crypt? And what do you gain from making it reutn "********** " > when that will never match anything? Hmmm.... If the dynamic linking of crypt types is too fragile, it will be too easy to force an error. If crypt _previously_ returned a "*************", and now can do it by generating an error, it will match. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE