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): 2.0.52-32.ent.centos4 How reproducible: Always. 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 step 1.): GET / HTTP/1.1 Host: <hostname> Connection: close Expect: FooBarBaz Actual results: The 417 error response is not returned until a connection timeout. Expected results: A 417 error shoudl be returned immediately. Additional info: 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.