[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1106281357430.17115@wotan.suse.de>
Date: Tue, 28 Jun 2011 14:05:35 +0200 (CEST)
From: Michael Matz <matz@...e.de>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com,
Ludwig Nussel <ludwig.nussel@...e.de>,
Thorsten Kukuk <kukuk@...e.de>, Andreas Jaeger <aj@...e.de>
Subject: Re: CVE request: crypt_blowfish 8-bit character
mishandling
Hi,
On Mon, 27 Jun 2011, Solar Designer wrote:
> > What's this 0xff business that crept up recently? It's all characters
> > with the high bit set, not just 0xff, that pose problems. Let's be
> > precise with these issues.
>
> We're considering the state we'll be in after upgrade to fixed code.
> 0xff is the only known practical way to have a correctly computed hash
> match one computed by the buggy code in cases where the latter was in
> fact computed incorrectly. Since a large subset of such incorrectly
> computed hashes had some of the original passwords' characters ignored,
> some working passwords for them are too easy to find, including in some
> cases passwords that will work even after the bug in the code is fixed.
> Those passwords will contain specifically the 0xff character. This is
> why we may want to treat the 0xff character specially.
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.
If so, treating passwords containing 0xff special seems sensible.
Ciao,
Michael.
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.
