Bug 245481 - Invalid Expect header not immediately rejected
Invalid Expect header not immediately rejected
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: httpd (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2007-06-23 17:15 EDT by Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail}
Modified: 2007-11-16 20:14 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-03 16:03:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Apache Bugzilla 38123 None None None Never

  None (edit)
Description Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 17:15:54 EDT
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):


How reproducible:


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.)
Comment 1 Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 17:46:52 EDT
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.
Comment 2 Joe Orton 2007-07-03 16:03:26 EDT
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.
Comment 3 Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-07-26 07:46:12 EDT
The argument about `Content-Length: 100' seems fair enough.

Note You need to log in before you can comment on or make changes to this bug.