[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2011 16:32:08 +0400
From: Solar Designer <solar@...nwall.com>
To: Ludwig Nussel <ludwig.nussel@...e.de>
Cc: oss-security@...ts.openwall.com, Michael Matz <matz@...e.de>,
Thorsten Kukuk <kukuk@...e.de>, Andreas Jaeger <aj@...e.de>,
Zefram <zefram@...h.org>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling
Ludwig, all -
On Fri, Jul 08, 2011 at 01:31:03AM +0400, Solar Designer wrote:
> On Thu, Jul 07, 2011 at 10:05:07AM +0200, Ludwig Nussel wrote:
> > mkpasswd (package whois) checks whether the crypted password starts
> > with the originally requested prefix. Since crypt_gensalt now
> > returns $2y for $2a mkpasswd fails. I'm not claiming mkpasswd's
> > assumption on the behavior of crypt_gensalt is correct but it's not
> > documented whether crypt_gensalt may change the prefix.
>
> Thank you for letting me know. Yes, this prefix change in
> crypt_gensalt*() was a hack, which I didn't give much thought yet.
> It would have been nice to be able to switch to using $2y$ for
> crypt_gensalt*()-aware apps (including our pam_tcb) just by upgrading
> glibc, without changes to any other component nor to a config file, but
> I agree that we'll want to avoid surprises like that. I'll change my
> code to preserve the requested prefix.
I took care of this in 1.1.2, still unreleased.
http://www.openwall.com/tmp/crypt_blowfish-1.1.2.tar.gz
I also did some testing to make sure the safety measure for $2a$
actually works (on passwords deliberately constructed to result in
collisions with multiple passwords input to the buggy algorithm) and to
see whether and how often it is triggered inadvertently (on passwords
that are not deliberately malicious, but just happen to be among those).
One conclusion is that, yes, the countermeasure works - not a single
failure on thousands of malicious passwords produced by the bcrypt_x2a
external filter to JtR. In all of those cases, the hashes were computed
using the altered algorithm, thereby avoiding collisions with the buggy
algorithm's hashes. I also made sure that $2x$ vs. $2y$ would in fact
produce collisions for all of those passwords (except for the different
prefix, which prevents the problem).
The other conclusion is that the countermeasure is almost harmless, as
expected. It got triggered on one non-deliberately-malicious password
in over 150,000 where each contained the 0xff character. Of those
150,000+, over 50,000 were produced by replacing a common letter in
Russian words in koi8-r encoding with the 0xff character, and the
remaining 100,000 by doing a similar thing to the top 100,000+ entries
of "all.lst", which contains common passwords, English words, etc.
Over the entire set of passwords, where most don't include the 0xff
character, the countermeasure will be triggered even more infrequently.
It is never triggered without 0xff, and rarely triggered with 0xff.
So I think it is OK to have it, and there's no need to bother
implementing compatibility support for those extremely rare altered
hashes in other tools.
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.
