[Fwd: APR Developer Advisory CVE-2009-2412]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

FYI

-------- Original Message --------
Subject: APR Developer Advisory CVE-2009-2412
Date: Tue, 04 Aug 2009 15:23:04 -0500
From: William A. Rowe, Jr. <wr...@rowe-clan.net>
To: APR Developer List <de...@apr.apache.org>

The APR project thanks Matt Lewis for bringing this overflow flaw to
the project's attention.  The project has released patches for the
CVE-2009-2412 at <http://www.apache.org/dist/apr/patches/> based on
his guidance.  The APR project expects to ship APR release 1.3.8 and
APR-util release 1.3.9 over the course of the week.

  http://www.apache.org/dist/apr/patches/

    apr-0.9-CVE-2009-2412.patch
    apr-1.x-CVE-2009-2412.patch
    apr-util-0.9-CVE-2009-2412.patch
    apr-util-1.x-CVE-2009-2412.patch

Abuse of this flaw required the developer to request an allocation of
an untrusted size, which the APR developers determined to indicate a
flaw in the developer's code.  Due to APR's behavior, however, an
application which exposed itself to such flaw was further vulnerable
due to a non-null return value from pool or rmm allocation calls.
Under normal scenarios, NULL should be returned, which is either
detected or leads to an immediate segfault/halt.  Due to APR's handling
of these allocation calls, data pollution and other side effects cannot
be ruled out, so APR had assigned CVE-2009-2412 <http://cve.mitre.org/>
to this issue.  The APR project recommends all distributors update to
include this patch or the forthcoming APR release, to guard against the
greater impact of future exploits of library consumers' vulnerable code.

Re: [Fwd: APR Developer Advisory CVE-2009-2412]

[Ruediger Pluem <rp...@apache.org>]

On 08/05/2009 09:23 PM, William A. Rowe, Jr. wrote:
>> Abuse of this flaw required the developer to request an allocation of
>> an untrusted size, which the APR developers determined to indicate a
>> flaw in the developer's code.  Due to APR's behavior, however, an
>> application which exposed itself to such flaw was further vulnerable
>> due to a non-null return value from pool or rmm allocation calls.
>> Under normal scenarios, NULL should be returned, which is either
>> detected or leads to an immediate segfault/halt.  Due to APR's handling
>> of these allocation calls, data pollution and other side effects cannot
>> be ruled out, so APR had assigned CVE-2009-2412 <http://cve.mitre.org/>
>> to this issue.  The APR project recommends all distributors update to
>> include this patch or the forthcoming APR release, to guard against the
>> greater impact of future exploits of library consumers' vulnerable code.
> 
> In short, this is unlikely to affect httpd.
> 
> But it's entirely possible that it affects third party modules built for
> httpd plus apr.  I'm willing to tag and roll this evening a 2.2.13 if people
> will stand behind voting for it over the next two days.

Go ahead. I am willing to give it a test.

Regards

Rüdiger

Re: [Fwd: APR Developer Advisory CVE-2009-2412]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> 
> Abuse of this flaw required the developer to request an allocation of
> an untrusted size, which the APR developers determined to indicate a
> flaw in the developer's code.  Due to APR's behavior, however, an
> application which exposed itself to such flaw was further vulnerable
> due to a non-null return value from pool or rmm allocation calls.
> Under normal scenarios, NULL should be returned, which is either
> detected or leads to an immediate segfault/halt.  Due to APR's handling
> of these allocation calls, data pollution and other side effects cannot
> be ruled out, so APR had assigned CVE-2009-2412 <http://cve.mitre.org/>
> to this issue.  The APR project recommends all distributors update to
> include this patch or the forthcoming APR release, to guard against the
> greater impact of future exploits of library consumers' vulnerable code.

In short, this is unlikely to affect httpd.

But it's entirely possible that it affects third party modules built for
httpd plus apr.  I'm willing to tag and roll this evening a 2.2.13 if people
will stand behind voting for it over the next two days.

Unfortunately, I'm unable to release it after 9am Sunday morning, so if we
want to push ahead with a 48 hour voting clock, please raise your hand to
test between thurs and fri.

I raised the idea in security@ discussion of re-releasing 2.2.12 with the
updated APR; nothing in the httpd svn tree suggested this specific version.
But since that idea received mixed reviews, it doesn't seem like the right
solution.

Bill