The following issue was reported against Traffic Server 5.0.0 - 5.1.1: Receiving a HTTP TRACE request containing a "Max-Forwards" header with a value of "0" will cause the traffic_server process to crash with an assertion failure, even in release builds. The parent process, traffic_manager, will restart the traffic_server process when it sees that it has crashed. However, it takes several seconds before the new process is ready to handle requests, during which the server appears unresponsive to the outside world. Also, traffic_manager will queue incoming requests until the new process is ready to handle them. These queued requests might consist of more of the same request that caused the traffic_server process to crash in the first place. This allows a remote attacker to perform an effective DoS of the server with very little resources by simply sending the crashing request repeatedly. References: Bug entry: https://issues.apache.org/jira/browse/TS-3223 Fix: https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=8b5f0345dade6b2822d9b52c8ad12e63011a5c12 Release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327089&styleName=Html&projectId=12310963 CVE request: http://seclists.org/oss-sec/2015/q1/69
Created trafficserver tracking bugs for this issue: Affects: fedora-21 [bug 1179204] Affects: epel-7 [bug 1179205]
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.