Date: Mon, 20 Jun 2011 18:05:54 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling On Mon, Jun 20, 2011 at 09:35:52AM +0100, Daniel God?s wrote: > This is the most sensible email I've seen on this list in ages. Keep up the > good work! Thank you for the encouragement. However, I find other messages on the list sensible as well. The recent discussion around /bin/su brought up important and interesting issues; I wanted to participate in that discussion, but I ran out of time, so I did not dare to start to comment. Returning to the crypt_blowfish topic, I am considering keeping support for the broken hashes under another prefix - say, "$2x$" (where the "x" would stand for "sign eXtension bug") instead of the usual "$2a$". For typical passwords, they'd be the same (except for this one letter in the prefix). Their potential use would be by a sysadmin wishing to avoid any service disruption for anyone (even if that means potentially staying with weaker passwords than what some users might have expected; maybe password changes would then be recommended or forced over time). That sysadmin would replace "$2a$" with "$2x$" in existing hashes on the system right before upgrade to corrected software (such as PHP or glibc with crypt_blowfish). Alternatively, say, a custom web app could be making this replacement for crypt() calls only, on hashes created before upgrade date. If we were the primary/official source of bcrypt hashes, we'd simply consider "$2a$" as corresponding to the buggy implementation and move to "$2b$", but since we're not and since correctly implemented bcrypt hashes are also in use, I am thinking to do it the other way around (as above). Does anyone need this? Or do we just assume that passwords with non-ASCII characters are uncommon enough that we can bite the bullet (of fixing the bug) without providing any backwards compatibility workaround? Also, this recently discovered bug reminds me of a near miss we had when a certain version of gcc (IIRC, it was 4.1.0) miscompiled the Blowfish code in JtR, but luckily not in crypt_blowfish. JtR would detect the error and refuse to run, but crypt_blowfish, if it were affected as well, would only detect it on explicit "make check". It would not detect that error on a mere call by an application such as PHP, unless "make check" or equivalent was done at compile time of that application. The effect would be incompatible and potentially weaker hashes. Thus, I am thinking of enhancing crypt_blowfish to always self-test itself briefly, to detect possible miscompiles. At "$2a$08", which is the default on Owl, there are 513 invocations of BF_body() (or equivalent). For a reasonably complete (in terms of code coverage) yet faster self-test, I can reduce this to 3. That's approx. a 0.6% slowdown, which I find acceptable. I'd appreciate comments. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.