RHSA-2017:1802HighCVSS 9.8

Red Hat Security Advisory: Red Hat JBoss Web Server Service Pack 1 security update

Published
July 25, 2017
Last Modified
August 4, 2026

🔗 CVE IDs covered (9)

CVE-2017-5648 →CVE-2017-5664 →CVE-2016-6304 →CVE-2017-7674 →CVE-2019-17571 →CVE-2016-7056 →CVE-2016-8610 →CVE-2017-5645 →CVE-2017-5647 →

📋 Description

CVE-2016-6304 — openssl: OCSP Status Request extension unbounded memory growth CVE-2016-7056 — openssl: ECDSA P-256 timing attack key recovery CVE-2016-8610 — SSL/TLS: Malformed plain-text ALERT packets could cause remote DoS CVE-2017-5645 — log4j: Socket receiver deserialization vulnerability CVE-2017-5647 — tomcat: Incorrect handling of pipelined requests when send file was used CVE-2017-5648 — tomcat: Calls to application listeners did not use the appropriate facade object CVE-2017-5664 — tomcat: Security constrained bypass in error page mechanism CVE-2017-7674 — tomcat: Vary header not added by CORS filter leading to cache poisoning CVE-2019-17571 — log4j: deserialization of untrusted data in SocketServer

🎯 Affected products1

  • Red Hat JBoss Web Server 3.1

✅ Remediation

Before applying the update, back up your existing Red Hat JBoss Web Server installation (including all applications and configuration files). The References section of this erratum contains a download link (you must log in to download the update). Workaround: The AJP connector does not support the sendfile capability. A server configured to only use the AJP connector (disable HTTP Connector) is not affected by this vulnerability. Disable the sendfile capability by setting useSendfile="false" in the HTTP connector configuration. Note: Disabling sendfile, may impact performance on large files. Workaround: If it is necessary to have the DefaultServlet property readonly=false, use a jsp error page, for example Error404.jsp rather than a static html error page. Alternatively do not specify an error-page in the Deployment Descriptor and use a custom ErrorReportValve. Workaround: Please note that the Log4j upstream strongly recommends against using the SerializedLayout with the SocketAppenders. Customers may mitigate this issue by removing the SocketServer class outright; or if they must continue to use SocketAppenders, they can modify their SocketAppender configuration from SerializedLayout to use JsonLayout instead. An example of this in log4j-server.properties might look like this: log4j.appender.file.layout=org.apache.log4j.JsonLayout

🔗 References (11)