RHSA-2017:2638HighCVSS 9.8

Red Hat Security Advisory: jboss-ec2-eap security, bug fix, and enhancement update

Published
September 5, 2017
Last Modified
August 4, 2026

🔗 CVE IDs covered (4)

CVE-2017-5645 →CVE-2017-5664 →CVE-2017-7525 →CVE-2019-17571 →

📋 Description

CVE-2017-5645 — log4j: Socket receiver deserialization vulnerability CVE-2017-5664 — tomcat: Security constrained bypass in error page mechanism CVE-2017-7525 — jackson-databind: Deserialization vulnerability via readValue method of ObjectMapper CVE-2019-17571 — log4j: deserialization of untrusted data in SocketServer

🎯 Affected products4

  • Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Server
  • jboss-ec2-eap-0:7.5.17-1.Final_redhat_4.ep6.el6.noarch as a component of Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Server
  • jboss-ec2-eap-0:7.5.17-1.Final_redhat_4.ep6.el6.src as a component of Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Server
  • jboss-ec2-eap-samples-0:7.5.17-1.Final_redhat_4.ep6.el6.noarch as a component of Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Server

✅ Remediation

Before applying this update, back up your existing Red Hat JBoss Enterprise Application Platform installation and deployed applications. For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 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: Mitigation to this problem is to not trigger polymorphic desrialization globally by using: objectMapper.enableDefaultTyping() and rather use @JsonTypeInfo on the class property to explicitly define the type information. For more information on this issue please refer to https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true 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 (7)