oss-sec mailing list archives
Re: *BSD's DES-based crypt(3) treats all invalid salt chars as '.'
From: Solar Designer <solar () openwall com>
Date: Tue, 15 Nov 2011 08:16:14 +0400
On Tue, Nov 15, 2011 at 07:54:04AM +0400, Solar Designer wrote:
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.
Speaking of NetBSD, it also appears to have out of bounds array reads on salt characters with the 8th bit set: static unsigned char a64toi[128]; /* ascii-64 => 0..63 */ [...] /* get iteration count */ num_iter = 0; for (i = 4; --i >= 0; ) { if ((t = (unsigned char)setting[i]) == '\0') t = '.'; encp[i] = t; num_iter = (num_iter<<6) | a64toi[t]; } [...] salt = 0; for (i = salt_size; --i >= 0; ) { if ((t = (unsigned char)setting[i]) == '\0') t = '.'; encp[i] = t; salt = (salt<<6) | a64toi[t]; } This has no security impact that I can see, though. Perhaps with PHP safe_mode and the like it could be used to read data beyond array bounds, but unless the order of variables in .bss is heavily changed by the compiler or linker there's nothing interesting to read in the 128 bytes following a64toi[], and it would not result in a crash either. Alexander
Current thread:
- *BSD's DES-based crypt(3) treats all invalid salt chars as '.' Solar Designer (Nov 14)
- Re: *BSD's DES-based crypt(3) treats all invalid salt chars as '.' Solar Designer (Nov 14)