(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.
simon 2009-06-21 15:45:18 UTC
FreeBSD ports repository
ports-mgmt/portaudit/files portaudit-cmd.sh portaudit.1
Download portaudit database from http://portaudit.FreeBSD.org/ instead
This is primarily done to work around bug in lighttpd on www.FreeBSD.org
where If-Modified-Since isn't handled correctly possibly resulting in
users behind web proxies getting an outdated version of the portaudit
Bump portaudit version number.
Big thanks to the reporter for the detailed PR with good information
about reproducing the issue.
Reported by: Christian Ullrich <firstname.lastname@example.org>
Prodding by: remko, Christian Ullrich
Revision Changes Path
1.25 +1 -1 ports/ports-mgmt/portaudit/Makefile
1.15 +2 -2 ports/ports-mgmt/portaudit/files/portaudit-cmd.sh
1.9 +3 -3 ports/ports-mgmt/portaudit/files/portaudit.1
1.7 +2 -2 ports/ports-mgmt/portaudit/files/portaudit.conf
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"
This had been fixed by Simon.