You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2014/03/30 12:13:20 UTC

Affected versions for CVE-2014-0098

Hi,

I have been looking at backporting the cookie issue fix, and it looks 
to me that it was introduced in

http://svn.apache.org/viewvc?view=revision&revision=r1374538
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/loggers/mod_log_config.c?r1=1374538&r2=1374537&pathrev=1374538

which would mean that versions before 2.2.23 are not affected. Can 
anyone verify this?

I couldn't produce a segfault even with 2.2.23, but with 2.2.22 the 
access log always contains the "-" for no value, while with the above 
commit, it logs an empty value. This probably means that in my setup, 
there is by coincidence always another NUL byte after the end of 
string NUL byte. This would be consistent with the reporter stating 
that he only saw it a few times in a month on a busy server.

If I am correct, the version list at
http://httpd.apache.org/security/vulnerabilities_22.html
should be adjusted.

Cheers,
Stefan


Re: Affected versions for CVE-2014-0098

Posted by Joe Orton <jo...@redhat.com>.
On Sun, Mar 30, 2014 at 12:13:20PM +0200, Stefan Fritsch wrote:
> Hi,
> 
> I have been looking at backporting the cookie issue fix, and it looks 
> to me that it was introduced in
> 
> http://svn.apache.org/viewvc?view=revision&revision=r1374538
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/loggers/mod_log_config.c?r1=1374538&r2=1374537&pathrev=1374538
> 
> which would mean that versions before 2.2.23 are not affected. Can 
> anyone verify this?

2.2.17 through 2.2.21 inclusive are vulnerable to CVE-2012-0021.

CVE-2012-0021 was introduced in 2.2.17:

http://svn.apache.org/viewvc?view=revision&revision=988403

CVE-2012-0021 was fixed in 2.2.22:

http://svn.apache.org/viewvc?view=revision&revision=1227292 

CVE-2014-0098 was introduced in 2.2.23:

http://svn.apache.org/viewvc?view=revision&revision=1374538 

But the code in 2.2.16 and earlier has the same strlen(x) + 1 pattern 
which leads to an overread in CVE-2014-0098.  We (RH) treated earlier 
2.2.x as vulnerable to CVE-2014-0098, it is essentially the same bug.

The claim that 2.2.17 through .22 inclusive are *not* vulnerable to 
CVE-2014-0098 looks correct to me but I have not verified.  I have 
verified that the pre-2.2.17 (pre r988403) code is vulnerable to 
CVE-2014-0098, although harder to trigger.

Regards, Joe