[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110620001516.GA27926@openwall.com>
Date: Mon, 20 Jun 2011 04:15:16 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Either my test script is b0rken or BF has an 8-bit bug
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
