You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by mj...@apache.org on 2010/03/08 16:29:33 UTC
svn commit: r920358 - in /httpd/site/trunk:
docs/security/vulnerabilities-oval.xml docs/security/vulnerabilities_22.html
xdocs/security/vulnerabilities-httpd.xml xdocs/stylesheets/httpd-oval.xsl
xdocs/stylesheets/securitydb.xsl
Author: mjc
Date: Mon Mar 8 15:29:32 2010
New Revision: 920358
URL: http://svn.apache.org/viewvc?rev=920358&view=rev
Log:
If we're going to start listing acknowledgements
here let's mark them out separately.
Modified:
httpd/site/trunk/docs/security/vulnerabilities-oval.xml
httpd/site/trunk/docs/security/vulnerabilities_22.html
httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml
httpd/site/trunk/xdocs/stylesheets/httpd-oval.xsl
httpd/site/trunk/xdocs/stylesheets/securitydb.xsl
Modified: httpd/site/trunk/docs/security/vulnerabilities-oval.xml
URL: http://svn.apache.org/viewvc/httpd/site/trunk/docs/security/vulnerabilities-oval.xml?rev=920358&r1=920357&r2=920358&view=diff
==============================================================================
--- httpd/site/trunk/docs/security/vulnerabilities-oval.xml (original)
+++ httpd/site/trunk/docs/security/vulnerabilities-oval.xml Mon Mar 8 15:29:32 2010
@@ -10,8 +10,7 @@
<title>Subrequest handling of request headers (mod_headers)</title>
<reference source="CVE" ref_id="CVE-2010-0434" ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0434"/>
<description>
-Philip Pickett of VMware reported a flaw with a proposed fix to the core
-subrequest process code, to always provide a shallow copy of the headers_in
+A flaw in the core subrequest process code was fixed, to always provide a shallow copy of the headers_in
array to the subrequest, instead of a pointer to the parent request's array
as it had for requests without request bodies. This meant all modules such
as mod_headers which may manipulate the input headers for a subrequest would
@@ -21,6 +20,9 @@
before the main request processing was finished, resulting in a segfault or
in revealing data from another request on threaded servers, such as the worker
or winnt MPMs.
+
+We would like to thank Philip Pickett of VMware for reporting and proposing a
+fix for this issue.
</description>
<apache_httpd_repository>
<public>20091209</public>
@@ -51,13 +53,15 @@
<title>mod_isapi module unload flaw</title>
<reference source="CVE" ref_id="CVE-2010-0425" ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0425"/>
<description>
-Brett Gervasoni of Sense of Security reported and proposed a patch fix
-for a flaw with within mod_isapi, which would attempt to unload the ISAPI dll when it
+A flaw was found with within mod_isapi which would attempt to unload the ISAPI dll when it
encountered various error states. This could leave the callbacks in an
undefined state and result in a segfault. On Windows platforms using mod_isapi, a
remote attacker could send a malicious request to trigger this issue, and as win32 MPM runs only one
process, this would result in a denial of service, and potentially allow
arbitrary code execution.
+
+We would like to thank Brett Gervasoni of Sense of Security for reporting and
+proposing a patch fix for this issue.
</description>
<apache_httpd_repository>
<public>20100302</public>
@@ -88,11 +92,13 @@
<title>mod_proxy_ajp DoS</title>
<reference source="CVE" ref_id="CVE-2010-0408" ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0408"/>
<description>
-Niku Toivola of Sulake Corporation reported, with a corresponding patch,
-that mod_proxy_ajp would return the wrong status code if it encountered
+mod_proxy_ajp would return the wrong status code if it encountered
an error, causing a backend server to be put into an error state until
the retry timeout expired. A remote attacker could send malicious requests
to trigger this issue, resulting in denial of service.
+
+We would like to thank Niku Toivola of Sulake Corporation for reporting and
+proposing a patch fix for this issue.
</description>
<apache_httpd_repository>
<public>20100302</public>
Modified: httpd/site/trunk/docs/security/vulnerabilities_22.html
URL: http://svn.apache.org/viewvc/httpd/site/trunk/docs/security/vulnerabilities_22.html?rev=920358&r1=920357&r2=920358&view=diff
==============================================================================
--- httpd/site/trunk/docs/security/vulnerabilities_22.html [utf-8] (original)
+++ httpd/site/trunk/docs/security/vulnerabilities_22.html [utf-8] Mon Mar 8 15:29:32 2010
@@ -105,8 +105,7 @@
</b>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0425">CVE-2010-0425</a>
<p>
-Brett Gervasoni of Sense of Security reported and proposed a patch fix
-for a flaw with within mod_isapi, which would attempt to unload the ISAPI dll when it
+A flaw was found with within mod_isapi which would attempt to unload the ISAPI dll when it
encountered various error states. This could leave the callbacks in an
undefined state and result in a segfault. On Windows platforms using mod_isapi, a
remote attacker could send a malicious request to trigger this issue, and as win32 MPM runs only one
@@ -115,6 +114,12 @@
</p>
</dd>
<dd>
+<p>Acknowledgements:
+We would like to thank Brett Gervasoni of Sense of Security for reporting and
+proposing a patch fix for this issue.
+</p>
+</dd>
+<dd>
Update Released: 5th March 2010<br />
</dd>
<dd>
@@ -128,8 +133,7 @@
</b>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0434">CVE-2010-0434</a>
<p>
-Philip Pickett of VMware reported a flaw with a proposed fix to the core
-subrequest process code, to always provide a shallow copy of the headers_in
+A flaw in the core subrequest process code was fixed, to always provide a shallow copy of the headers_in
array to the subrequest, instead of a pointer to the parent request's array
as it had for requests without request bodies. This meant all modules such
as mod_headers which may manipulate the input headers for a subrequest would
@@ -142,6 +146,12 @@
</p>
</dd>
<dd>
+<p>Acknowledgements:
+We would like to thank Philip Pickett of VMware for reporting and proposing a
+fix for this issue.
+</p>
+</dd>
+<dd>
Update Released: 5th March 2010<br />
</dd>
<dd>
@@ -155,14 +165,19 @@
</b>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0408">CVE-2010-0408</a>
<p>
-Niku Toivola of Sulake Corporation reported, with a corresponding patch,
-that mod_proxy_ajp would return the wrong status code if it encountered
+mod_proxy_ajp would return the wrong status code if it encountered
an error, causing a backend server to be put into an error state until
the retry timeout expired. A remote attacker could send malicious requests
to trigger this issue, resulting in denial of service.
</p>
</dd>
<dd>
+<p>Acknowledgements:
+We would like to thank Niku Toivola of Sulake Corporation for reporting and
+proposing a patch fix for this issue.
+</p>
+</dd>
+<dd>
Update Released: 5th March 2010<br />
</dd>
<dd>
Modified: httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml
URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml?rev=920358&r1=920357&r2=920358&view=diff
==============================================================================
--- httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml [utf-8] (original)
+++ httpd/site/trunk/xdocs/security/vulnerabilities-httpd.xml [utf-8] Mon Mar 8 15:29:32 2010
@@ -6,8 +6,7 @@
<severity level="4">low</severity>
<title>Subrequest handling of request headers (mod_headers)</title>
<description><p>
-Philip Pickett of VMware reported a flaw with a proposed fix to the core
-subrequest process code, to always provide a shallow copy of the headers_in
+A flaw in the core subrequest process code was fixed, to always provide a shallow copy of the headers_in
array to the subrequest, instead of a pointer to the parent request's array
as it had for requests without request bodies. This meant all modules such
as mod_headers which may manipulate the input headers for a subrequest would
@@ -18,6 +17,10 @@
in revealing data from another request on threaded servers, such as the worker
or winnt MPMs.
</p></description>
+<acknowledgements>
+We would like to thank Philip Pickett of VMware for reporting and proposing a
+fix for this issue.
+</acknowledgements>
<affects prod="httpd" version="2.2.14"/>
<affects prod="httpd" version="2.2.13"/>
<affects prod="httpd" version="2.2.12"/>
@@ -37,14 +40,17 @@
<severity level="2">important</severity>
<title>mod_isapi module unload flaw</title>
<description><p>
-Brett Gervasoni of Sense of Security reported and proposed a patch fix
-for a flaw with within mod_isapi, which would attempt to unload the ISAPI dll when it
+A flaw was found with within mod_isapi which would attempt to unload the ISAPI dll when it
encountered various error states. This could leave the callbacks in an
undefined state and result in a segfault. On Windows platforms using mod_isapi, a
remote attacker could send a malicious request to trigger this issue, and as win32 MPM runs only one
process, this would result in a denial of service, and potentially allow
arbitrary code execution.
</p></description>
+<acknowledgements>
+We would like to thank Brett Gervasoni of Sense of Security for reporting and
+proposing a patch fix for this issue.
+</acknowledgements>
<affects prod="httpd" version="2.2.14"/>
<affects prod="httpd" version="2.2.13"/>
<affects prod="httpd" version="2.2.12"/>
@@ -64,12 +70,15 @@
<severity level="3">moderate</severity>
<title>mod_proxy_ajp DoS</title>
<description><p>
-Niku Toivola of Sulake Corporation reported, with a corresponding patch,
-that mod_proxy_ajp would return the wrong status code if it encountered
+mod_proxy_ajp would return the wrong status code if it encountered
an error, causing a backend server to be put into an error state until
the retry timeout expired. A remote attacker could send malicious requests
to trigger this issue, resulting in denial of service.
</p></description>
+<acknowledgements>
+We would like to thank Niku Toivola of Sulake Corporation for reporting and
+proposing a patch fix for this issue.
+</acknowledgements>
<affects prod="httpd" version="2.2.14"/>
<affects prod="httpd" version="2.2.13"/>
<affects prod="httpd" version="2.2.12"/>
Modified: httpd/site/trunk/xdocs/stylesheets/httpd-oval.xsl
URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/stylesheets/httpd-oval.xsl?rev=920358&r1=920357&r2=920358&view=diff
==============================================================================
--- httpd/site/trunk/xdocs/stylesheets/httpd-oval.xsl (original)
+++ httpd/site/trunk/xdocs/stylesheets/httpd-oval.xsl Mon Mar 8 15:29:32 2010
@@ -190,7 +190,7 @@
<xsl:attribute name="ref_id"><xsl:value-of select="$cveid"/></xsl:attribute>
<xsl:attribute name="ref_url">http://cve.mitre.org/cgi-bin/cvename.cgi?name=<xsl:value-of select="$cveid"/></xsl:attribute>
</xsl:element>
- <description><xsl:value-of select="../description/p"/></description>
+ <description><xsl:value-of select="../description/p"/><xsl:value-of select="../acknowledgements"/></description>
<!--
The <apache_httpd_repository> piece of metadata is not required by
the OVAL schema but is valid due the <xsd:any> tag found in the
Modified: httpd/site/trunk/xdocs/stylesheets/securitydb.xsl
URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/stylesheets/securitydb.xsl?rev=920358&r1=920357&r2=920358&view=diff
==============================================================================
--- httpd/site/trunk/xdocs/stylesheets/securitydb.xsl (original)
+++ httpd/site/trunk/xdocs/stylesheets/securitydb.xsl Mon Mar 8 15:29:32 2010
@@ -62,6 +62,12 @@
<xsl:copy-of select="description/*"/>
</dd>
+ <xsl:if test="acknowledgements != ''">
+ <dd>
+ <p>Acknowledgements: <xsl:value-of select="acknowledgements"/></p>
+ </dd>
+ </xsl:if>
+
<dd>
<xsl:if test="@released != ''">
Update Released: <xsl:call-template name="dateformat">