Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jun 2011 09:35:52 +0100
From: Daniel Godás <>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling

This is the most sensible email I've seen on this list in ages. Keep up the
good work!

2011/6/20 Solar Designer <>

> Hi,
> Earlier today, while working on a test suite for John the Ripper, magnum
> discovered and reported what turned out to be a bug in John the Ripper
> and crypt_blowfish:
> The bug is inadvertent sign extension, and the fix is trivial:
> This bug dates back to 1998 (or maybe even 1997).
> Unfortunately, the bug is not only in JtR, but also in crypt_blowfish,
> and thus in plenty of other systems and programs that have integrated
> crypt_blowfish.  Obviously, I am quite embarrassed; I should have
> included 8-bit test vectors or subjected crypt_blowfish to a fuzzer (vs.
> OpenBSD's implementation), or/and used different coding conventions (use
> "unsigned char" almost everywhere, although this has its problems too -
> such as compiler warnings on library calls that expect simple "char *").
> Since the code successfully worked in JtR, I thought that it was
> essentially already fuzz-tested.  But apparently passwords with 8-bit
> characters were uncommon enough that no one noticed the bug for years.
> I am going to provide an official fix for crypt_blowfish (likely the
> one-liner plus added tests).  I thought I'd bring the issue up on
> oss-security sooner rather than later.
> Here's my preliminary analysis of the impact:
> To summarize:
> The majority of hashes (but not all of them) for passwords containing
> characters with the 8th bit set are incompatible with OpenBSD's (really
> nasty, but no security impact here).
> What's worse, approximately 3 in 16 passwords containing a single
> character with the 8th bit set have 1 to 3 characters immediately
> preceding the 8-bit character ignored.  With more than one character
> with the 8th bit set, things may be even worse.
> Thus, those passwords may be much easier to crack than expected.
> As to what's affected besides crypt_blowfish itself, I expect it to be
> PHP (the code in php-5.3.7RC1 looks affected), Linux distros that use
> crypt_blowfish (Owl, ALT Linux, SUSE), and some others (I'll try to
> identify them and notify the maintainers).
> Sorry about that!
> Since this is the second bug with char signedness in crypt_blowfish, it
> looks like I have a lesson to learn here.  The last time, the bug was
> with salt generation for hash types other than bcrypt (that code was
> little used and little tested).  Besides fixing the bug, I responded by
> running extensive tests and making sure the distribution of salts was
> uniform.  Of course, it was better to run those tests before releasing
> the code to the public.  Now we have an issue with the passwords
> themselves.  Obviously, I will be adding more tests, even though it
> would be better done before releasing the code.
> No, I don't expect even more sign extension bugs in crypt_blowfish.
> There's not that much code, and we've pretty much tested it by now.
> However, I might reconsider my C programming conventions for new code as
> it relates to use of integer types.  I think I'd rather workaround
> meaningless compiler warnings on strlen() and the like (even though
> those extra casts look dirty) than miss real bugs elsewhere.
> Perl's Crypt::Eksblowfish turns out to have sufficiently reworked code
> that it's unaffected:
> Oh, also some builds of crypt_blowfish (and of affected systems/apps)
> for PowerPC are probably unaffected, because char is typically unsigned
> there (unless overridden in compiler flags for compatibility with more
> typical systems).
> Once again, my apologies for the mess.
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ