Mailing List Archive

svn commit: r1064088 - in /websites/staging/httpd/trunk/content: ./ security/vulnerabilities-httpd.xml security/vulnerabilities_24.html
Author: buildbot
Date: Sat Aug 8 12:17:25 2020
New Revision: 1064088

Log:
Staging update by buildbot for httpd

Modified:
websites/staging/httpd/trunk/content/ (props changed)
websites/staging/httpd/trunk/content/security/vulnerabilities-httpd.xml
websites/staging/httpd/trunk/content/security/vulnerabilities_24.html

Propchange: websites/staging/httpd/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Aug 8 12:17:25 2020
@@ -1 +1 @@
-1880677
+1880700

Modified: websites/staging/httpd/trunk/content/security/vulnerabilities-httpd.xml
==============================================================================
--- websites/staging/httpd/trunk/content/security/vulnerabilities-httpd.xml (original)
+++ websites/staging/httpd/trunk/content/security/vulnerabilities-httpd.xml Sat Aug 8 12:17:25 2020
@@ -6,7 +6,7 @@
<title>mod_proxy_uwsgi buffer overflow </title>
<description>
<p>
- Apache HTTP Server versions 2.4.32 to 2.4.44 <br />
+ Apache HTTP Server versions 2.4.32 to 2.4.43<br />
mod_proxy_uwsgi info disclosure and possible RCE
</p>
</description>
@@ -57,40 +57,6 @@
<affects prod="httpd" version="2.4.23"/>
<affects prod="httpd" version="2.4.20"/>
</issue>
-<issue reported="20161013" public="20200807">
- <cve name="CVE-2020-11985"/>
-
- <severity level="4">low</severity>
- <title>IP address spoofing when proxying using mod_remoteip and mod_rewrite</title>
- <description>
- <p>
- For configurations using proxying with mod_remoteip and certain
- mod_rewrite rules, an attacker could spoof their IP address for
- logging and PHP scripts.
- </p><p>
- Note this issue was fixed in Apache HTTP Server 2.4.24 but was
- retrospectively allocated a low severity CVE in 2020.
- </p>
- </description>
- <acknowledgements>
-
- </acknowledgements>
- <fixed base="2.4" version="2.4.25" date="20200807"/>
- <affects prod="httpd" version="2.4.23"/>
- <affects prod="httpd" version="2.4.20"/>
- <affects prod="httpd" version="2.4.18"/>
- <affects prod="httpd" version="2.4.17"/>
- <affects prod="httpd" version="2.4.16"/>
- <affects prod="httpd" version="2.4.12"/>
- <affects prod="httpd" version="2.4.10"/>
- <affects prod="httpd" version="2.4.9"/>
- <affects prod="httpd" version="2.4.7"/>
- <affects prod="httpd" version="2.4.6"/>
- <affects prod="httpd" version="2.4.4"/>
- <affects prod="httpd" version="2.4.3"/>
- <affects prod="httpd" version="2.4.2"/>
- <affects prod="httpd" version="2.4.1"/>
-</issue>
<issue reported="20200424" public="20200807">
<cve name="CVE-2020-9490"/>

@@ -1419,6 +1385,41 @@ We would like to thank ChenQin and Hanno
<affects prod="httpd" version="2.2.0"/>
</issue>

+<issue reported="20161013" public="20200807">
+ <cve name="CVE-2020-11985"/>
+
+ <severity level="4">low</severity>
+ <title>IP address spoofing when proxying using mod_remoteip and mod_rewrite</title>
+ <description>
+ <p>
+ For configurations using proxying with mod_remoteip and certain
+ mod_rewrite rules, an attacker could spoof their IP address for
+ logging and PHP scripts.
+ </p><p>
+ Note this issue was fixed in Apache HTTP Server 2.4.24 but was
+ retrospectively allocated a low severity CVE in 2020.
+ </p>
+ </description>
+ <acknowledgements>
+
+ </acknowledgements>
+ <fixed base="2.4" version="2.4.25" date="20200807"/>
+ <affects prod="httpd" version="2.4.23"/>
+ <affects prod="httpd" version="2.4.20"/>
+ <affects prod="httpd" version="2.4.18"/>
+ <affects prod="httpd" version="2.4.17"/>
+ <affects prod="httpd" version="2.4.16"/>
+ <affects prod="httpd" version="2.4.12"/>
+ <affects prod="httpd" version="2.4.10"/>
+ <affects prod="httpd" version="2.4.9"/>
+ <affects prod="httpd" version="2.4.7"/>
+ <affects prod="httpd" version="2.4.6"/>
+ <affects prod="httpd" version="2.4.4"/>
+ <affects prod="httpd" version="2.4.3"/>
+ <affects prod="httpd" version="2.4.2"/>
+ <affects prod="httpd" version="2.4.1"/>
+</issue>
+
<issue reported="20160210" public="20161220">
<fixed base="2.4" version="2.4.25" date="20161220"/>
<fixed base="2.2" version="2.2.32" date="20170113"/>

Modified: websites/staging/httpd/trunk/content/security/vulnerabilities_24.html
==============================================================================
--- websites/staging/httpd/trunk/content/security/vulnerabilities_24.html (original)
+++ websites/staging/httpd/trunk/content/security/vulnerabilities_24.html Sat Aug 8 12:17:25 2020
@@ -157,7 +157,7 @@ Fixed in Apache httpd 2.4.44</h1><dl>
</dt>
<dd>
<p>
- Apache HTTP Server versions 2.4.32 to 2.4.44 <br/>
+ Apache HTTP Server versions 2.4.32 to 2.4.43<br/>
mod_proxy_uwsgi info disclosure and possible RCE
</p>
<p>Acknowledgements:
@@ -220,319 +220,6 @@ Fixed in Apache httpd 2.4.44</h1><dl>
</tr>
</table>
</dd>
-</dl><br/><h1 id="2.4.25">
-Fixed in Apache httpd 2.4.25</h1><dl>
- <dt>
- <h3 id="CVE-2016-8743">important:
- <name name="CVE-2016-8743">Apache HTTP Request Parsing Whitespace Defects</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8743">CVE-2016-8743</a>)
- </h3>
- </dt>
- <dd>
- <p>
-Apache HTTP Server, prior to release 2.4.25 (2.2.32), accepted a broad pattern
-of unusual whitespace patterns from the user-agent, including bare CR, FF, VTAB
-in parsing the request line and request header lines, as well as HTAB in
-parsing the request line. Any bare CR present in request lines was treated
-as whitespace and remained in the request field member "the_request", while
-a bare CR in the request header field name would be honored as whitespace,
-and a bare CR in the request header field value was retained the input headers
-array. Implied additional whitespace was accepted in the request line and prior
-to the ':' delimiter of any request header lines.
-</p>
- <p>
-RFC7230 Section 3.5 calls out some of these whitespace exceptions, and section
-3.2.3 eliminated and clarified the role of implied whitespace in the grammer
-of this specification. Section 3.1.1 requires exactly one single SP between the
-method and request-target, and between the request-target and HTTP-version,
-followed immediately by a CRLF sequence. None of these fields permit any
-(unencoded) CTL character whatsoever. Section 3.2.4 explicitly disallowed
-any whitespace from the request header field prior to the ':' character, while
-Section 3.2 disallows all CTL characters in the request header line other than
-the HTAB character as whitespace.
-</p>
- <p>
-These defects represent a security concern when httpd is participating in any
-chain of proxies or interacting with back-end application servers, either
-through mod_proxy or using conventional CGI mechanisms. In each case where one
-agent accepts such CTL characters and does not treat them as whitespace, there
-is the possiblity in a proxy chain of generating two responses from a server
-behind the uncautious proxy agent. In a sequence of two requests, this results
-in request A to the first proxy being interpreted as requests A + A' by the
-backend server, and if requests A and B were submitted to the first proxy in
-a keepalive connection, the proxy may interpret response A' as the response
-to request B, polluting the cache or potentially serving the A' content to
-a different downstream user-agent.
-</p>
- <p>
-These defects are addressed with the release of Apache HTTP Server 2.4.25
-and coordinated by a new directive;
-</p>
- <ul>
- <li>
-<a href="http://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions">HttpProtocolOptions Strict</a></li>
- </ul>
- <p>
-which is the default behavior of 2.4.25 and later. By toggling from 'Strict'
-behavior to 'Unsafe' behavior, some of the restrictions may be relaxed to allow
-some invalid HTTP/1.1 clients to communicate with the server, but this will
-reintroduce the possibility of the problems described in this assessment.
-Note that relaxing the behavior to 'Unsafe' will still not permit raw CTLs
-other than HTAB (where permitted), but will allow other RFC requirements to
-not be enforced, such as exactly two SP characters in the request line.
-</p>
- <p>Acknowledgements:
-We would like to thank David Dennerline at IBM Security's X-Force Researchers
-as well as Régis Leroy for each reporting this issue.
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">10th February 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2020-11985">low:
- <name name="CVE-2020-11985">IP address spoofing when proxying using mod_remoteip and mod_rewrite</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11985">CVE-2020-11985</a>)
- </h3>
- </dt>
- <dd>
- <p>
- For configurations using proxying with mod_remoteip and certain
- mod_rewrite rules, an attacker could spoof their IP address for
- logging and PHP scripts.
- </p>
- <p>
- Note this issue was fixed in Apache HTTP Server 2.4.24 but was
- retrospectively allocated a low severity CVE in 2020.
- </p>
- <p>Acknowledgements:
-
- </p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">13th October 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">7th August 2020</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">7th August 2020</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2016-8740">low:
- <name name="CVE-2016-8740">HTTP/2 CONTINUATION denial of service</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8740">CVE-2016-8740</a>)
- </h3>
- </dt>
- <dd>
- <p>
- The HTTP/2 protocol implementation (mod_http2) had an incomplete handling
- of the
- <a href="https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfields">LimitRequestFields</a>
- directive. This allowed an attacker to inject unlimited request headers into
- the server, leading to eventual memory exhaustion.
-</p>
- <p>Acknowledgements:
-We would like to thank Naveen Tiwari
-and CDF/SEFCOM at Arizona State University to reporting this issue.
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">22nd November 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">4th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2016-2161">low:
- <name name="CVE-2016-2161">DoS vulnerability in mod_auth_digest</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2161">CVE-2016-2161</a>)
- </h3>
- </dt>
- <dd>
- <p>
- Malicious input to mod_auth_digest will cause the server to crash, and
- each instance continues to crash even for subsequently valid requests.
-</p>
- <p>Acknowledgements:
-We would like to thank Maksim Malyutin for reporting this issue.
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">11th July 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2016-0736">low:
- <name name="CVE-2016-0736">Padding Oracle in Apache mod_session_crypto</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0736">CVE-2016-0736</a>)
- </h3>
- </dt>
- <dd>
- <p>
- Prior to Apache HTTP release 2.4.25, mod_sessioncrypto was encrypting its
- data/cookie using the configured ciphers with possibly either CBC or ECB
- modes of operation (AES256-CBC by default), hence no selectable or builtin
- authenticated encryption.
- This made it vulnerable to padding oracle attacks, particularly with CBC.
- An authentication tag (SipHash MAC) is now added to prevent such attacks.
-</p>
- <p>Acknowledgements:
-We would like to thank individuals at the RedTeam Pentesting GmbH for reporting
-this issue.
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">20th January 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2016-4975">moderate:
- <name name="CVE-2016-4975">mod_userdir CRLF injection</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4975">CVE-2016-4975</a>)
- </h3>
- </dt>
- <dd>
- <p>
-Possible CRLF injection allowing HTTP response splitting attacks
-for sites which use mod_userdir. This issue was
-mitigated by changes made in 2.4.25 and 2.2.32 which prohibit CR or LF
-injection into the "Location" or other outbound
-header key or value.
-</p>
- <p>Acknowledgements:
-The issue was discovered by Sergey Bobrov
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">24th July 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">14th August 2018</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
- <dt>
- <h3 id="CVE-2016-5387">n/a:
- <name name="CVE-2016-5387">HTTP_PROXY environment variable "httpoxy" mitigation</name>
- (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5387">CVE-2016-5387</a>)
- </h3>
- </dt>
- <dd>
- <p>
- HTTP_PROXY is a well-defined environment variable in a CGI process,
- which collided with a number of libraries which failed to avoid
- colliding with this CGI namespace. A mitigation is provided for the
- httpd CGI environment to avoid populating the "HTTP_PROXY" variable
- from a "Proxy:" header, which has never been registered by IANA.
-</p>
- <p>
- This workaround and patch are documented in the ASF Advisory at
- <a href="https://www.apache.org/security/asf-httpoxy-response.txt">asf-httpoxy-response.txt</a>
- and incorporated in the 2.4.25 and 2.2.32 releases.
-</p>
- <p>
- Note: This is not assigned an httpd severity, as it is a defect in
- other software which overloaded well-established CGI environment
- variables, and does not reflect an error in HTTP server software.
-</p>
- <p>Acknowledgements:
-We would like to thank Dominic Scheirlinck and Scott Geary of Vend
-for reporting and proposing a fix for this issue.
-</p>
- <table class="cve">
- <tr>
- <td class="cve-header">Reported to security team</td>
- <td class="cve-value">2nd July 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Issue public</td>
- <td class="cve-value">18th July 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Update Released</td>
- <td class="cve-value">20th December 2016</td>
- </tr>
- <tr>
- <td class="cve-header">Affects</td>
- <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
- </tr>
- </table>
- </dd>
</dl><br/><h1 id="2.4.42">
Fixed in Apache httpd 2.4.42</h1><dl>
<dt>
@@ -1792,6 +1479,319 @@ We would like to thank ChenQin and Hanno
</tr>
</table>
</dd>
+</dl><br/><h1 id="2.4.25">
+Fixed in Apache httpd 2.4.25</h1><dl>
+ <dt>
+ <h3 id="CVE-2016-8743">important:
+ <name name="CVE-2016-8743">Apache HTTP Request Parsing Whitespace Defects</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8743">CVE-2016-8743</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+Apache HTTP Server, prior to release 2.4.25 (2.2.32), accepted a broad pattern
+of unusual whitespace patterns from the user-agent, including bare CR, FF, VTAB
+in parsing the request line and request header lines, as well as HTAB in
+parsing the request line. Any bare CR present in request lines was treated
+as whitespace and remained in the request field member "the_request", while
+a bare CR in the request header field name would be honored as whitespace,
+and a bare CR in the request header field value was retained the input headers
+array. Implied additional whitespace was accepted in the request line and prior
+to the ':' delimiter of any request header lines.
+</p>
+ <p>
+RFC7230 Section 3.5 calls out some of these whitespace exceptions, and section
+3.2.3 eliminated and clarified the role of implied whitespace in the grammer
+of this specification. Section 3.1.1 requires exactly one single SP between the
+method and request-target, and between the request-target and HTTP-version,
+followed immediately by a CRLF sequence. None of these fields permit any
+(unencoded) CTL character whatsoever. Section 3.2.4 explicitly disallowed
+any whitespace from the request header field prior to the ':' character, while
+Section 3.2 disallows all CTL characters in the request header line other than
+the HTAB character as whitespace.
+</p>
+ <p>
+These defects represent a security concern when httpd is participating in any
+chain of proxies or interacting with back-end application servers, either
+through mod_proxy or using conventional CGI mechanisms. In each case where one
+agent accepts such CTL characters and does not treat them as whitespace, there
+is the possiblity in a proxy chain of generating two responses from a server
+behind the uncautious proxy agent. In a sequence of two requests, this results
+in request A to the first proxy being interpreted as requests A + A' by the
+backend server, and if requests A and B were submitted to the first proxy in
+a keepalive connection, the proxy may interpret response A' as the response
+to request B, polluting the cache or potentially serving the A' content to
+a different downstream user-agent.
+</p>
+ <p>
+These defects are addressed with the release of Apache HTTP Server 2.4.25
+and coordinated by a new directive;
+</p>
+ <ul>
+ <li>
+<a href="http://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions">HttpProtocolOptions Strict</a></li>
+ </ul>
+ <p>
+which is the default behavior of 2.4.25 and later. By toggling from 'Strict'
+behavior to 'Unsafe' behavior, some of the restrictions may be relaxed to allow
+some invalid HTTP/1.1 clients to communicate with the server, but this will
+reintroduce the possibility of the problems described in this assessment.
+Note that relaxing the behavior to 'Unsafe' will still not permit raw CTLs
+other than HTAB (where permitted), but will allow other RFC requirements to
+not be enforced, such as exactly two SP characters in the request line.
+</p>
+ <p>Acknowledgements:
+We would like to thank David Dennerline at IBM Security's X-Force Researchers
+as well as Régis Leroy for each reporting this issue.
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">10th February 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2020-11985">low:
+ <name name="CVE-2020-11985">IP address spoofing when proxying using mod_remoteip and mod_rewrite</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11985">CVE-2020-11985</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+ For configurations using proxying with mod_remoteip and certain
+ mod_rewrite rules, an attacker could spoof their IP address for
+ logging and PHP scripts.
+ </p>
+ <p>
+ Note this issue was fixed in Apache HTTP Server 2.4.24 but was
+ retrospectively allocated a low severity CVE in 2020.
+ </p>
+ <p>Acknowledgements:
+
+ </p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">13th October 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">7th August 2020</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">7th August 2020</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2016-8740">low:
+ <name name="CVE-2016-8740">HTTP/2 CONTINUATION denial of service</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8740">CVE-2016-8740</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+ The HTTP/2 protocol implementation (mod_http2) had an incomplete handling
+ of the
+ <a href="https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfields">LimitRequestFields</a>
+ directive. This allowed an attacker to inject unlimited request headers into
+ the server, leading to eventual memory exhaustion.
+</p>
+ <p>Acknowledgements:
+We would like to thank Naveen Tiwari
+and CDF/SEFCOM at Arizona State University to reporting this issue.
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">22nd November 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">4th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2016-2161">low:
+ <name name="CVE-2016-2161">DoS vulnerability in mod_auth_digest</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2161">CVE-2016-2161</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+ Malicious input to mod_auth_digest will cause the server to crash, and
+ each instance continues to crash even for subsequently valid requests.
+</p>
+ <p>Acknowledgements:
+We would like to thank Maksim Malyutin for reporting this issue.
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">11th July 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2016-0736">low:
+ <name name="CVE-2016-0736">Padding Oracle in Apache mod_session_crypto</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0736">CVE-2016-0736</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+ Prior to Apache HTTP release 2.4.25, mod_sessioncrypto was encrypting its
+ data/cookie using the configured ciphers with possibly either CBC or ECB
+ modes of operation (AES256-CBC by default), hence no selectable or builtin
+ authenticated encryption.
+ This made it vulnerable to padding oracle attacks, particularly with CBC.
+ An authentication tag (SipHash MAC) is now added to prevent such attacks.
+</p>
+ <p>Acknowledgements:
+We would like to thank individuals at the RedTeam Pentesting GmbH for reporting
+this issue.
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">20th January 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2016-4975">moderate:
+ <name name="CVE-2016-4975">mod_userdir CRLF injection</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4975">CVE-2016-4975</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+Possible CRLF injection allowing HTTP response splitting attacks
+for sites which use mod_userdir. This issue was
+mitigated by changes made in 2.4.25 and 2.2.32 which prohibit CR or LF
+injection into the "Location" or other outbound
+header key or value.
+</p>
+ <p>Acknowledgements:
+The issue was discovered by Sergey Bobrov
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">24th July 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">14th August 2018</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
+ <dt>
+ <h3 id="CVE-2016-5387">n/a:
+ <name name="CVE-2016-5387">HTTP_PROXY environment variable "httpoxy" mitigation</name>
+ (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5387">CVE-2016-5387</a>)
+ </h3>
+ </dt>
+ <dd>
+ <p>
+ HTTP_PROXY is a well-defined environment variable in a CGI process,
+ which collided with a number of libraries which failed to avoid
+ colliding with this CGI namespace. A mitigation is provided for the
+ httpd CGI environment to avoid populating the "HTTP_PROXY" variable
+ from a "Proxy:" header, which has never been registered by IANA.
+</p>
+ <p>
+ This workaround and patch are documented in the ASF Advisory at
+ <a href="https://www.apache.org/security/asf-httpoxy-response.txt">asf-httpoxy-response.txt</a>
+ and incorporated in the 2.4.25 and 2.2.32 releases.
+</p>
+ <p>
+ Note: This is not assigned an httpd severity, as it is a defect in
+ other software which overloaded well-established CGI environment
+ variables, and does not reflect an error in HTTP server software.
+</p>
+ <p>Acknowledgements:
+We would like to thank Dominic Scheirlinck and Scott Geary of Vend
+for reporting and proposing a fix for this issue.
+</p>
+ <table class="cve">
+ <tr>
+ <td class="cve-header">Reported to security team</td>
+ <td class="cve-value">2nd July 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Issue public</td>
+ <td class="cve-value">18th July 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Update Released</td>
+ <td class="cve-value">20th December 2016</td>
+ </tr>
+ <tr>
+ <td class="cve-header">Affects</td>
+ <td class="cve-value">2.4.23, 2.4.20, 2.4.18, 2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2, 2.4.1</td>
+ </tr>
+ </table>
+ </dd>
</dl><br/><h1 id="2.4.23">
Fixed in Apache httpd 2.4.23</h1><dl>
<dt>