www/134505: www.freebsd.org does not correctly process
If-Modified-Since requests
Christian Ullrich
chris at chrullrich.net
Wed May 13 08:20:04 UTC 2009
>Number: 134505
>Category: www
>Synopsis: www.freebsd.org does not correctly process If-Modified-Since requests
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-www
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed May 13 08:20:04 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator: Christian Ullrich
>Release: n/a
>Organization:
>Environment:
n/a
>Description:
(While this issue has security implications, it does not do so _directly_, so I think that a public bug report is OK. I'm calling it a "serious" bug anyway.)
The HTTP server at www.freebsd.org fails to correctly process requests with the If-Modified-Since header (for HTTP/1.0, see RFC 1945, section 10.9). This affects, among other things, downloads of the portaudit vulnerability index file at <http://www.freebsd.org/ports/auditfile.tbz>.
When portaudit accesses this file directly, it does not send an If-Modified-Since header, but if there is a cache in the way, the portaudit run that is part of the daily security cron job will fail.
Sample HTTP dialog (some headers removed):
> GET /ports/auditfile.tbz HTTP/1.0
> If-Modified-Since: Wed, 06 May 2009 10:10:07 GMT
> Host: www.freebsd.org
> User-Agent: fetch libfetch/2.0
> Via: 1.1 my.squid.local
> Cache-Control: max-age=0
> Connection: keep-alive
< HTTP/1.0 304 Not Modified
< Connection: keep-alive
< Content-Type: application/x-bzip-compressed-tar
< Accept-Ranges: bytes
< ETag: "1975729766"
< Last-Modified: Wed, 13 May 2009 07:10:04 GMT
< Date: Wed, 13 May 2009 07:33:00 GMT
< Server: httpd/1.4.x LaHonda
The 304 response leads to squid delivering its cached copy of the file.
squid does not verify that the Last-Modified date the server provided is in fact less than or equal to the If-Modified-Since date squid sent, nor does it compare the ETag to that of the cached copy.
In some experimental requests, I have come to the conclusion that the inclusion of an If-Modified-Since request header containing _any_ valid "rfc1123-date" (using the term from RFC 1945) will result in a 304 response. If the header values does not match this syntax, or if the date is invalid in a blatant way, a 200 response is sent.
>How-To-Repeat:
curl --header "If-Modified-Since: Thu, 1 Jan 1970 00:00:00 GMT" -I http://www.freebsd.org/ports/auditfile.tbz
Note the 304 response.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-www
mailing list