[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110620140554.GA30897@openwall.com>
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.
