[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120330195639.57a62a09@redhat.com>
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[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
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.
