Synopsis: Moderate: httpd security and bug fix update
Advisory ID: SLSA-2017:0906-1
Issue Date: 2017-04-12
CVE Numbers: CVE-2016-0736
* It was discovered that the mod_session_crypto module of httpd did not
use any mechanisms to verify integrity of the encrypted session data
stored in the user’s browser. A remote attacker could use this flaw to
decrypt and modify session data using a padding oracle attack.
* It was discovered that the mod_auth_digest module of httpd did not
properly check for memory allocation failures. A remote attacker could use
this flaw to cause httpd child processes to repeatedly crash if the server
used HTTP digest authentication. (CVE-2016-2161)
* It was discovered that the HTTP parser in httpd incorrectly allowed
certain characters not permitted by the HTTP protocol specification to
appear unencoded in HTTP request headers. If httpd was used in conjunction
with a proxy or backend server that interpreted those characters
differently, a remote attacker could possibly use this flaw to inject data
into HTTP responses, resulting in proxy cache poisoning. (CVE-2016-8743)
Note: The fix for the CVE-2016-8743 issue causes httpd to return “400 Bad
Request” error to HTTP clients which do not strictly follow HTTP protocol
specification. A newly introduced configuration directive
“HttpProtocolOptions Unsafe” can be used to re-enable the old less strict
parsing. However, such setting also re-introduces the CVE-2016-8743 issue.
* When waking up child processes during a graceful restart, the httpd
parent process could attempt to open more connections than necessary if a
large number of child processes had been active prior to the restart.
Consequently, a graceful restart could take a long time to complete. With
this update, httpd has been fixed to limit the number of connections
opened during a graceful restart to the number of active children, and the
described problem no longer occurs.
* Previously, httpd running in a container returned the 500 HTTP status
code (Internal Server Error) when a connection to a WebSocket server was
closed. As a consequence, the httpd server failed to deliver the correct
HTTP status and data to a client. With this update, httpd correctly
handles all proxied requests to the WebSocket server, and the described
problem no longer occurs.
* In a configuration using LDAP authentication with the mod_authnz_ldap
module, the name set using the AuthLDAPBindDN directive was not correctly
used to bind to the LDAP server for all queries. Consequently,
authorization attempts failed. The LDAP modules have been fixed to ensure
the configured name is correctly bound for LDAP queries, and authorization
using LDAP no longer fails.
– Scientific Linux Development Team