Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120330181725.GA30972@openwall.com>
Date: Fri, 30 Mar 2012 22:17:25 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Jeff Law <law@...hat.com>
Subject: Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()

Tomas - thank you for notifying oss-security of this.
Jeff - thank you for working on a fix.

On Fri, Mar 30, 2012 at 07:56:39PM +0200, Tomas Hoger wrote:
> FYI, a fix just got committed upstream,

Wow.  I thought we'd need to notify glibc developers more specifically
for this to happen, which I did not do yet for lack of decision on what
to do with the return value.

> 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

I think the NULL returns are a bad idea, and this aspect doesn't appear
to have been discussed.  We may want to check if there were other cases
where glibc's crypt() could return NULL, then propose a separate patch
on libc-alpha.  So far, the "*0" / "*1" approach appears to be best:

http://www.openwall.com/lists/oss-security/2011/11/15/1

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.