Bug 245481 - Invalid Expect header not immediately rejected
Summary: Invalid Expect header not immediately rejected
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: httpd
Version: 4.5
Hardware: All
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-23 21:15 UTC by Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail}
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-03 20:03:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache Bugzilla 38123 0 None None None Never

Description Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 21:15:54 UTC
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.)

Comment 1 Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 21:46:52 UTC
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 20:03:26 UTC
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 11:46:12 UTC
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.