[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE request: crypt_blowfish 8-bit character mishandling
From:       Solar Designer <solar () openwall ! com>
Date:       2011-06-29 21:53:34
Message-ID: 20110629215334.GA15871 () openwall ! com
[Download RAW message or body]

On Tue, Jun 28, 2011 at 02:05:35PM +0200, Michael Matz wrote:
> Thanks, so, let me see if I got this: the original password contained some 
> 8bit chars (0xff or not doesn't matter), the buggy hashes lead to easily 
> finding passwords with the same hash, some of those conflicting passwords 
> might have 0xff chars in them, and _those_ then will sometimes still 
> produce a hash conflict even with the fixed blowfish code.

The above is almost right, but not exactly.  Not all buggy hashes for
passwords with 8-bit chars lead to easily finding other passwords with
the same hash, but many do.

Simple example:

With the buggy code, all of: "\xa3", "ab\xa3", and "\xff\xff\xa3"
produce the same hash.

With the fixed code, "\xff\xff\xa3" is the only easily found password
that produces that same hash.

(This matches your understanding.)

No extra unauthorized access risk, OpenBSD compatible hash:

With the buggy code, "\xa3" "ab" (3 chars total) produces a certain
hash.  No other password may be easily found that produces the same hash.

With the fixed code, the same password produces the same hash.  (So the
user can log in.)

No extra unauthorized access risk, OpenBSD incompatible hash:

With the buggy code, "a\xa3" (2 chars total) produces a certain hash.
No other password may be easily found that produces the same hash.

With the fixed code, no password may be easily found that produces the
same hash.  (So the user cannot log in.)

Complicated example:

With the buggy code, "1\xa3" "345" (5 chars total) produces a certain
hash.  "\xff\xa3" "345" and some other strings produce the same hash.
Among those other strings is "\xff\xa3" "34" "\xff\xff\xff\xa3" "345"
(11 chars total).

With the fixed code, "\xff\xa3" "345" no longer produces the same hash,
but "\xff\xa3" "34" "\xff\xff\xff\xa3" "345" still does.

> If so, treating passwords containing 0xff special seems sensible.

Yes.  In "Simple" and "Complicated" examples above, an attacker wouldn't
need to know/guess some of the original password's characters to log in,
even after the code is fixed, unless we introduce special treatment of
0xff chars.

Alexander
[prev in list] [next in list] [prev in thread] [next in thread]