What we get when we play with this is: GET (chr13)<null> GET /(whatever we want to put in here) Anything after the null is not logged. However, apache also ignores it. I've been unable to get apache to serve up anything requested after the null. This could be usefull in hiding a buffer overflow from apaches logs, (maybe) but I think it's unlikely since apache seems to ignore the remainder of the string. putting together a huge request, (50,000 characters or so) generated this in the access log: 172.16.x.x - - [26/Apr/2001:14:40:34 -0400] "GET ^M" 414 347 and this in the error log: [Thu Apr 26 14:40:34 2001] [error] [client 172.16.x.x] request failed: URI too long Trimming that to 5000 characters or so generates only this: 172.16.x.x - - [26/Apr/2001:14:42:52 -0400] "GET ^M" 414 347 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsiat_private] > Sent: Wednesday, April 25, 2001 11:42 AM > To: VULN-DEVat_private > Subject: possible apache logging problem > > > Hi, > > We have discovered the following strange log entry in Apache > logs, which > seems to be _at least_ suspicious: > > xxx.xxx.xxx.xxx - - [24/Apr/2001:20:50:17 +0200] "^M" 200 > 37971 "-" "-" 0 www.xxxxx.hu > xxx.xxx.xxx.xxx - - [24/Apr/2001:20:50:57 +0200] "^M" 200 > 8445 "-" "-" 0 www.xxxxx.hu > > As you can see the URI part of the log message is a single CR > (ASCII 13) > character, and the answer of the server is 200, thus the > request was processed > successfully. Digging up the apache source revealed that Apache makes > it possible to include NUL characters in request lines, and > later works > with this string as a NUL terminated one. > > So if you issue a request like below: > > GET /something.html HTTP/1.0<NUL>GET /somethingelse.html HTTP/1.0 > > Then the second part of the request would not be logged. I > could not however > craft a request which made apache to interpret the characters > after the > <NUL>. Hiding the full request however was successful. > > My analysis on the Apache source code was only a quick review, but my > findings were the following: > > - apache happily reads lines with embedded NULs in his > ap_bgets() function > - this function is called by getline() in http_protocol.c, > which strips off > trailing spaces, and folds continuation lines (this is not requested > for the request line, so no folding is done) > - the line returned by getline() is strdupped into > request->the_request thus > stripping off anything after the NUL > - the line is processed by ap_getword_white() to parse > METHOD, URI and VERSION > - ap_getword_white() assumes that the string begins with the > word itself, > and scans for the first white-space character, this scan is > terminated > upon finding a NUL. If a NUL was found, the whole string is > duplicated, > otherwise characters up to the first white space characters > are duped. > > So I can't see a way of skipping that NUL, and I don't have > more time for > more analysis, but as the log entries show it should be > possible somehow. > > -- > Bazsi > PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD > 804E C82C 8EB1 >
This archive was generated by hypermail 2b30 : Thu Apr 26 2001 - 21:18:54 PDT