Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Mar 2012 19:56:39 +0200
From: Tomas Hoger <>
Subject: Re: glibc crypt(3), crypt_r(3), PHP crypt() may use

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:;a=commitdiff;h=b8dc394ddfd58bc5d0fe9ecfc970fc42b789a9df

Upstream discussion:

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.