|From:||Solar Designer <solar-cxoSlKxDwOJWk0Htik3J/w-AT-public.gmane.org>|
|Subject:||Re: Either my test script is b0rken or BF has an 8-bit bug|
|Date:||Mon, 20 Jun 2011 04:15:16 +0400|
magnum - On Mon, Jun 20, 2011 at 03:08:52AM +0400, Solar Designer wrote: > Now I am wondering how Authen::Passphrase avoided the bug (IIRC, it used > my code from crypt_blowfish), and why I am getting different hashes for > 8-bit chars produced by crypt() in Perl on Owl (which uses crypt_blowfish > in glibc on Owl). I'll need to investigate that. I have not investigated Authen::Passphrase yet, but your hash matches OpenBSD's. So it appears that Authen::Passphrase avoided or fixed the bug (knowingly or not). > If crypt_blowfish has > the bug too, and it looks like it does, that's pretty bad, because it > means we have incorrect (incompatible with OpenBSD's) hashes in the wild > as well. Moreover, those might be weaker than expected, as sign > expansion in the OR operation may be overwriting key bits from other > characters (the exact impact needs to be analyzed). I am quite > embarrassed of that. I should have tested the 8-bit chars vs. OpenBSD > myself, years ago (when I released crypt_blowfish separately from JtR). I confirmed the above. It is almost as bad as I thought it was. In my testing so far, I am able to construct password pairs that differ in two characters, yet produce the same hash on Owl. For example, "ab" followed by the pound sign ("\xa3" in C) produces the same hash as the pound sign alone does (when I use the same salt for testing, indeed): $2a$05$/OK.fbVrR/bpIqNJ5ianF.CE5elHaaO4EbggVDjb8P19RukzXSM3e This will require some non-trivial handling. Not only do we need to patch the bug in JtR and in crypt_blowfish, but we also need to get this change accepted into affected software (to be identified), and even then we could want to continue to support those alternate hashes available in the wild, maybe with some non-default setting in JtR (and in other apps?) Bugs in functions like this are really nasty. This reminds me how some implementations of MD5-crypt in early Linux-PAM had endianness bugs, which resulted in Linux-PAM carrying two implementations for a while. JtR does not support those wrong-endianness MD5-crypt hashes, though, so maybe it shouldn't support the wrong bcrypt ones either... For the common case, without 8-bit chars in passwords, nothing changes here. A curious detail is that some passwords with 8-bit chars are unaffected by the bug. For example, pound sign followed by "ab" (3 chars total) produces the same hash on OpenBSD and Owl. This is because the 24 sign extension bits are fully overwritten by "ab" and NUL. On Mon, Jun 20, 2011 at 03:20:26AM +0400, Solar Designer wrote: > I've just tried my Perl script on OpenBSD 4.6, invoking crypt(). It > produced the same hash as I am getting on Owl. However, that hash is > not cracked by John, neither with nor without the fix I posted. I'll > investigate further. That was an escaping bug in the Perl script invoked via "perl -e", now fixed for my further/real tests. Alexander
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds