Brett Hutley wrote:
Yup. Note that the way 2.0.40 handles this, it strdups WHATEVER is pushed through afterwards to the status_line member of the request_rec structure. This seems to me to be potentially dangerous... as in; push exploit machine code onto the heap through this function, and then take advantage of a smaller buffer overflow opportunity elsewhere to indirect through to your HUGE_STRING_LEN-13 sized exploit function... of course this depends on there actually BEING another buffer overflow opportunity elsewhere.... and being able to access the pointer to the request_rec structure, and then DNS-cache-poisoning the internal dns server so the web server proxies from the evil machine that serves the bad headers rather than the server you THINK you are proxying from... so it's very, very, unlikely to be exploited. The fix is so trivial though (make sure the HTTP response string length is greater than 13 bytes).
Hmmm, just realised that an attacker can send through the exploit code in the reason string anyway. I guess the patch will only help with broken servers sending through broken status lines in the response message (which, funnily enough, was it's original purpose). Please consider the above a momentary attack of insanity, while I give myself a good whack with the clue stick.
Cheers, Brett
