Date: Fri, 8 Jul 2011 16:32:08 +0400 From: Solar Designer <solar@...nwall.com> To: Ludwig Nussel <ludwig.nussel@...e.de> Cc: oss-security@...ts.openwall.com, Michael Matz <matz@...e.de>, Thorsten Kukuk <kukuk@...e.de>, Andreas Jaeger <aj@...e.de>, Zefram <zefram@...h.org> Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig, all - On Fri, Jul 08, 2011 at 01:31:03AM +0400, Solar Designer wrote: > On Thu, Jul 07, 2011 at 10:05:07AM +0200, Ludwig Nussel wrote: > > mkpasswd (package whois) checks whether the crypted password starts > > with the originally requested prefix. Since crypt_gensalt now > > returns $2y for $2a mkpasswd fails. I'm not claiming mkpasswd's > > assumption on the behavior of crypt_gensalt is correct but it's not > > documented whether crypt_gensalt may change the prefix. > > Thank you for letting me know. Yes, this prefix change in > crypt_gensalt*() was a hack, which I didn't give much thought yet. > It would have been nice to be able to switch to using $2y$ for > crypt_gensalt*()-aware apps (including our pam_tcb) just by upgrading > glibc, without changes to any other component nor to a config file, but > I agree that we'll want to avoid surprises like that. I'll change my > code to preserve the requested prefix. I took care of this in 1.1.2, still unreleased. http://www.openwall.com/tmp/crypt_blowfish-1.1.2.tar.gz I also did some testing to make sure the safety measure for $2a$ actually works (on passwords deliberately constructed to result in collisions with multiple passwords input to the buggy algorithm) and to see whether and how often it is triggered inadvertently (on passwords that are not deliberately malicious, but just happen to be among those). One conclusion is that, yes, the countermeasure works - not a single failure on thousands of malicious passwords produced by the bcrypt_x2a external filter to JtR. In all of those cases, the hashes were computed using the altered algorithm, thereby avoiding collisions with the buggy algorithm's hashes. I also made sure that $2x$ vs. $2y$ would in fact produce collisions for all of those passwords (except for the different prefix, which prevents the problem). The other conclusion is that the countermeasure is almost harmless, as expected. It got triggered on one non-deliberately-malicious password in over 150,000 where each contained the 0xff character. Of those 150,000+, over 50,000 were produced by replacing a common letter in Russian words in koi8-r encoding with the 0xff character, and the remaining 100,000 by doing a similar thing to the top 100,000+ entries of "all.lst", which contains common passwords, English words, etc. Over the entire set of passwords, where most don't include the 0xff character, the countermeasure will be triggered even more infrequently. It is never triggered without 0xff, and rarely triggered with 0xff. So I think it is OK to have it, and there's no need to bother implementing compatibility support for those extremely rare altered hashes in other tools. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ