[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111115035404.GA8377@openwall.com>
Date: Tue, 15 Nov 2011 07:54:04 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: *BSD's DES-based crypt(3) treats all invalid salt chars as '.'
Hi,
The traditional DES-based crypt(3) accepts a salt string consisting of
characters from a certain base-64 alphabet, normally encoding a 12-bit
salt value in two characters.
What happens when the salt string contains characters outside of the
usual base-64 alphabet is implementation-specific. Typically,
implementations map those invalid salts onto the 12-bit values in one of
several ways. FreeSec, an otherwise very good implementation by David
Burren, appears to be the only widespread implementation that maps all
invalid salt characters onto just one 6-bit value - zero. FreeSec is
the implementation used by FreeBSD, OpenBSD, DragonFly BSD. The code in
NetBSD is different, but it appears to share this problem. Indeed,
these systems don't use the DES-based hashes by default, and even if
they did they'd be OK because they'd use valid salts, but the issue here
is with third-party programs that are not as careful - especially web
apps invoking this code via PHP's crypt() (whether the underlying
system's crypt(3) or PHP's own code is used depends on PHP version and
build).
Thus, with poorly written programs combined with this property of
crypt(3) on *BSD's we get effectively matching salts, which a password
cracker aware of this property can take advantage of for much faster
offline attacks.
I patched the FreeSec code to match UFC-crypt's handling of invalid
salts about 20 months ago:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_freesec.c
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_freesec.h
This did not matter much for Owl because we do not actually override
glibc's UFC-crypt for the traditional hashes (we use FreeSec for
"extended" hashes with 24-bit salts, which are not produced by naive
apps), however I made those changes primarily for reuse of the code in
PHP - and the changes went into a certain version of PHP (5.3.2+, IIRC).
Now I welcome *BSD's to reuse these as well. Yes, this sort of breaks
compatibility with existing invalid-salt hashes produced on those
systems, but those will be easy to fix if necessary by explicitly
changing their invalid salt characters to '.' (and thus making the
problem even more apparent).
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.
