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.