Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ