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