Bug 43039 - NUL character is valid in header lines
Summary: NUL character is valid in header lines
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0.54
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2007-08-04 17:06 UTC by Ralf H
Modified: 2012-02-26 16:46 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf H 2007-08-04 17:06:41 UTC
using this request (perl code):

print "GET / HTTP/1.0\x00\r\n" .
      "User-Agent: abc\x00def\r\n".
      "  0\x00123\r\n" .
      "Connection: k\r\n".
      "\r\n";

access log says the UA is "abc".
Comment 1 André Malo 2007-08-04 17:29:37 UTC
I don't quite see your point.

My reading of RFC 2616 says, that the 0-octet is invalid in header lines. So the
httpd has the choice between rejecting the request and accepting it like he
wants to - and takes the latter (being lenient...).
Comment 2 Ruediger Pluem 2007-08-05 02:29:19 UTC
Besides the RFC argument accepting 0 characters opens a large can of worms for
all kind of attacks. Nearly all application firewalls disallow 0 characters for
very good reasons. I think requests as the one described should be answered with
a status code 400. In the light that they currently result in a status code 200
I would see this as a valid bug.
Comment 3 Ralf H 2007-08-05 14:26:05 UTC
(In reply to comment #1)
> I don't quite see your point.
> 
> My reading of RFC 2616 says, that the 0-octet is invalid in header lines.

Thats my point.

Why accepting invalid characters (and in this case the "special" NUL character)?

I dont know the side effects (somewhere deep inside the httpd code),
but i think no (real) client is sending \0 in a request.

On the other hand whats about:

print "GET / HTTP/1.0" . ("\x00" x 1000) . "\r\n\r\n";

(sends NUL 1000 times)

At the end this will result in 413/414 or something similar and the
httpd cant say why - it seams like a normal request.
Comment 4 Nick Kew 2009-12-20 16:41:31 UTC
Fixed in trunk in r892678
Comment 5 Stefan Fritsch 2012-02-26 16:46:02 UTC
fixed in 2.4.1