[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Nov 2011 08:16:14 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: *BSD's DES-based crypt(3) treats all invalid salt chars as '.'
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
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.
