Graham Leggett wrote:
Peter Van Biesen wrote:
Direct conntection :
# wget -S --proxy=off http://www.argenta.be --11:29:28-- http://www.argenta.be/ => `index.html.2' Resolving www.argenta.be... done. Connecting to www.argenta.be[62.233.1.156]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200
^^^^^^^^
Seems the "human readable" part of the response is missing, and the proxy is expecting at least an HTTP/x.x<space>200<space>, where the last space is missing.
Regards, Graham
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).
Cheers, Brett
