Date: Fri, 30 Mar 2012 19:56:39 +0200 From: Tomas Hoger <thoger@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca() 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 = '*'; > buffer = '0'; > buffer = '\0'; > if (salt == '*' && salt == '0') > buffer = '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
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.