It was discovered that a programming error in the processing of HTTPS requests in the Apache Tomcat servlet and JSP engine may result in denial of service via an infinite loop. Upstream patch: https://github.com/apache/tomcat80/commit/614e7f78aecc429d8740bb59900c2f9fbc86a788#diff-2aeb244142da5fcb78a54e23f717fcd2 Upstream bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=57544
External References: http://tomcat.apache.org/security-7.html https://access.redhat.com/articles/2991951
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4.14 Via RHSA-2017:0517 https://rhn.redhat.com/errata/RHSA-2017-0517.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 7 Via RHSA-2017:0828 https://rhn.redhat.com/errata/RHSA-2017-0828.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Via RHSA-2017:0827 https://rhn.redhat.com/errata/RHSA-2017-0827.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 5 Via RHSA-2017:0826 https://rhn.redhat.com/errata/RHSA-2017-0826.html
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Via RHSA-2017:0829 https://rhn.redhat.com/errata/RHSA-2017-0829.html
Upstream commits for 6.0 and 7.0: https://github.com/apache/tomcat60/commit/a7a913dd6c88342d36bbac800056cb6c9376e293 https://github.com/apache/tomcat70/commit/6bd022b904429148610b9fb4cdc8082f20a93ccb
Statement: This issue was made easier to exploit, causing a denial of service when the patch for CVE-2016-6816 was present and the patch that corrected this flaw was not. The issue was not classified as a security flaw upstream. It was corrected in products like Red Hat Enterprise Linux 6 and 7 and JBoss Enterprise Web Server 3 prior to the fix for CVE-2016-6816 being applied. This was not the case for JBoss Enterprise Application Server 6. As a result, only EAP 6.4.13 is vulnerable to this issue and 6.4.14 corrects it. For further information, refer to https://access.redhat.com/articles/2991951