Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()

[Tomas Hoger <thoger () redhat com>]

On Tue, 15 Nov 2011 06:13:24 +0400 Solar Designer wrote:

> Alternatively, crypt(3) and crypt_r(3) (and the reference code for
> SHA-crypt?) could refuse to work on overly long key or/and salt
> strings, but then the question is what they should do on error.
> crypt(3) returning NULL and setting errno is SUSv2-compliant, but in
> practice is unexpected by many programs.  Thus, I think the functions
> would need to return a string that is guaranteed not to match the
> salt string, e.g. with something like:
>
>       buffer[0] = '*';
>       buffer[1] = '0';
>       buffer[2] = '\0';
>       if (salt[0] == '*' && salt[1] == '0')
>               buffer[1] = '1';
>
> (but also need to check buflen).
>
> Finally, we could use malloc() instead of alloca(), but this doesn't
> eliminate the need to potentially handle an error condition (what if
> malloc() returns NULL?)

FYI, a fix just got committed upstream, which makes glibc use malloc
instead of alloca for long inputs and hence possibly make crypt() return
NULL on errors:

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b8dc394ddfd58bc5d0fe9ecfc970fc42b789a9df

Upstream discussion:

http://sourceware.org/ml/libc-alpha/2012-03/msg01138.html
http://sourceware.org/ml/libc-alpha/2012-03/msg01158.html

-- 
Tomas Hoger / Red Hat Security Response Team