Red Hat Bugzilla – Bug 245481
Invalid Expect header not immediately rejected
Last modified: 2007-11-16 20:14:56 EST
Description of problem:
When Apache is passed an unrecognized value for the `Expect' HTTP header, it
hangs until the connection times out.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open HTTP connection to a web server running affected version of Apache -- e.
g. run `telnet <hostname> http' (replace `<hostname>' with the server hostname).
2. Send a request similar to the one listed below.
3. Wait for the connection to time out before you get a reply.
The request could look like this (replace `<hostname>' with the same value as in
GET / HTTP/1.1
The 417 error response is not returned until a connection timeout.
A 417 error shoudl be returned immediately.
This is a known bug in Apache Bugzilla -- #38123. Even though it's been fixed
over a year ago, the bugfix made it into the 2.2 branch only. It would need to
be backported to 2.0.
If I understand the connections correctly, it cout be considered a minor
security bug allowing for a DoS attack. The timeout setting in default RHEL
config is 120 seconds (compiled-in value is even 300).
If I'm not mistaken, when the server blocks until a timeout, the serving child
process/thread is still allocated to the blocking request. By creating enough
such blocking request an attacker could make the server busy enough to refuse
any further request until one of the blocked requests times out.
Since this is known for some time, I'm not setting any cofidentiality flags.
May this be not as critical as one could think? (In such a case a brief
explanation could be useful before WONTFIXing this.)
Correction: version-release should read `2.0.52-32.ent (2.0.52-32.ent.centos4)'
as this was tested on CentOS but should apply to RHEL as well.
There are no security implications to the bug; it's just a very very minor issue
in error handling. The impact to the server is no different to that of a client
connection and sending "Content-Length: 100" then refusing to send any bytes -
the httpd child hangs until the read timeout is hit.
Since it is such a minor issue in an error handling condition (which is highly
unlikely to be triggered by real clients), and the patch is a subtle change to
core processing code, backporting the patch is not really advisable.
The argument about `Content-Length: 100' seems fair enough.