[owl-users] crypt_blowfish 1.1; Owl glibc security update

Hi,

I've just released crypt_blowfish 1.1:

http://www.openwall.com/crypt/

It fixes the 8-bit character handling bug (CVE-2011-2483) and adds 8-bit
test vectors and a quick self-test on every password hash computation.

Unfortunately, the bug had security impact, as I described in my initial
notification to oss-security members:

http://www.openwall.com/lists/oss-security/2011/06/20/2

Here's what changes I made to crypt_blowfish to address the bug, along
with potential future incorrect hash computation bugs/miscompiles:

http://www.openwall.com/lists/oss-security/2011/06/21/2

I've included a summary with more up-to-date understanding below.
So if you want to link to this from a blog post or whatever, please link
to this announcement, which will appear at:

http://www.openwall.com/lists/announce/2011/06/21/1

I'd like to thank magnum for his work on John the Ripper test suite,
which resulted in discovery of this bug.  (Yes, JtR also contains the
bug, to be addressed in the next release, but this is less of an issue.)

I would also like to apologize for this embarrassing bug, and for the
inconvenience it causes.  Sorry!  We are going to proceed to notify
third-party software maintainers who had integrated crypt_blowfish to
make sure they're aware of the issue and of availability of the fix, as
well as of the backwards compatibility feature (mentioned below).

At the same time, a glibc update is being made available for Owl-current.
(We'll get it into 3.0-stable soon.)  The only change is the new version
of crypt_blowfish.  Here's the CHANGES-current entry, re-formatted for
easier reading:

crypt_blowfish has been updated to version 1.1, which fixes the 8-bit
character handling bug and adds 8-bit test vectors and a quick self-test
on every password hash computation.  The impact of this bug was that
most (but not all) passwords containing non-ASCII characters with the
8th bit set were hashed incorrectly, resulting in password hashes
incompatible with those of OpenBSD's original implementation of bcrypt.

What's worse, in some cases (but not in all) one, two, or three
characters immediately preceding the 8-bit characters were ignored by
the password hash computation.  Thus, many passwords containing
characters with the 8th bit set are significantly easier to crack than
it was previously expected.

This primarily applies to offline attacks against the password hashes
(if they're leaked or stolen), but in rare extreme cases it might also
apply to remote password guessing attacks.  In practice, passwords with
non-ASCII characters are relatively uncommon and are typically more
complicated than average, so they're unlikely to be an attractive target
for attacks, despite of the weakness that this bug exposes them to.
Yet the risk is there.

With this glibc update, existing users' passwords containing characters
with the 8th bit set will mostly stop working, because the hashes will
be computed correctly and not match the incorrectly computed hashes
recorded in the system.  Please note that this does not always prevent
potential exploitation of the weakness described above; in some cases,
alternate passwords may be found that would produce those same hashes
under the correct algorithm.

Thus, it is recommended that any passwords containing characters with
the 8th bit set be changed after this upgrade.  In order to allow users
to log in after the upgrade even if they have a potentially affected
password, the newly introduced backwards compatibility hash encoding
prefix of "$2x$" may be used (in place of the usual "$2a$").  Such
password hashes should only be used during a transition period; when
passwords are changed, the usual "$2a$" prefix is used, denoting the
correct algorithm.

My apologies for the mess.  This is a rushed release.  We might come up
with a better upgrade strategy, especially as it's needed for systems
other than Owl as well.

Alexander