[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jun 2011 20:58:48 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Michael Matz <matz@...e.de>, Thorsten Kukuk <kukuk@...e.de>,
Andreas Jaeger <aj@...e.de>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling
On Mon, Jun 27, 2011 at 04:59:05PM +0200, Ludwig Nussel wrote:
> I think we cannot risk locking out users (which might include the
> admin) with a security update on a released product. So existing
> hashes have to keep working. My fear is that most systems just stay
> in that compat mode forever if we don't make some component complain
> though.
This makes sense. For Owl, I think we'll accept this lockout risk, but
warn our admins that they should make sure they're able to log in after
installing the update. In fact, it is a good practice to do this after
any upgrade to relevant components, such as to glibc, not only this time.
What about having a warning printed from %post in a relevant package?
Oh, I guess this won't achieve anything with automated updates.
> Ok, so we'd need two config options, one to toggle signedness bug
> compat mode (2a=2x) and one to disallow 0xff if compat mode is off.
I think you could do with just one option. When the compat mode is
enabled, you treat 2a in existing hashes as 2x. When it is disabled,
you stop doing that and you disallow 0xff chars in passwords being
authenticated against 2a hashes. In either mode, any new hashes are
marked with 2y, as long as the self-test is not disabled.
The 2y is certification of proper operation at least for the specific
test vector, which includes both 7- and 8-bit chars. This should catch
most miscompiles in the future, in case we get anything similar to the
gcc 4.1.0 bug that caused such a miscompile in JtR, but by pure luck not
in crypt_blowfish. I want some safety from that, hence I think the
self-test on every hash computation must not be disabled.
I am seriously considering making special treatment of 0xff with 2a the
default in crypt_blowfish itself. So you wouldn't need to have it in
your code, and I am the one to take care of timing issues. Yes, this
means that I deliberately break 2a somewhat vs. OpenBSD's, but this
might be the best way to resolve the situation we got into. The reality
is that right now 2a means "unknown correctness", unfortunately, and
treating only 0xff chars differently from OpenBSD is far less incorrect
than having the sign extension bug was.
> Default for for the security update would be bug compat mode on.
That's up to you to decide.
> In that mode new passwords would get the 2y prefix. The 0xff option
> has no effect. Over time the number of 2a passwords decreases. Once
> /etc/shadow contains no 2a passwords on important accounts anymore
> the admin could switch off bug compat mode
Right.
> and s/2y/2a/.
No. I think these should stay as-is.
> More nervous admins could disable bug compat mode right away. That
> would lock out affected users unless the admin also does s/2a/2x/.
Right.
> The really paranoid could additionally enable the 0xff option. New
> passwords would get 2a.
No, and no. I see no reason for either of these (assuming that you
implement what was discussed above).
> I suppose crypt_blowfish is not meant to parse some config file, so
> we'd have to implement the options in the pam modules.
Yes, but I think it'd be just one option, and its behavior will be as
trivial as to treat 2a on existing hashes as 2x. It shouldn't do
anything else. The 0xff thing will be in crypt_blowfish itself, per my
current proposal above - which I'd appreciate comments on.
Thanks,
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.
