Hi Alexey, [trimmed the CC list not to pollute mailboxes]
On Tue, Sep 25, 2012 at 02:37:52PM +0400, Alexey Vlasov wrote: > Here's another dump: > > [25/Sep/2012:12:54:00.380] frontend backend_pool610 (#15): invalid request > backend backend_pool610 (#15), server <NONE> (#-1), event #0 > src xx.xx.143.35:57191, session #27, session flags 0x00000080 > HTTP msg state 26, msg flags 0x00000000, tx flags 0x00000000 > HTTP chunk len 0 bytes, HTTP body len 0 bytes > buffer flags 0x00908002, out 0 bytes, total 938 bytes > pending 938 bytes, wrapping at 16384, error at position 23: > 00000 GET /phpinfo.php?PATH=/????????????? > 00034+ ?????/&&pid=42 HTTP/1.1 > ... > 00622 X-FORWARDED-URI: /%D0%9A%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/&pid=42 > 00691+ > 00692 X-FORWARDED-REQUEST: GET > /%D0%9A%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/& > 00762+ pid=42 HTTP/1.1 > > The full request should be like the following: > GET /phpinfo.php?PATH=/??????????????/&&pid=42 HTTP/1.1 > > But as it can be seen from the dump, show error shows an unknown symbol "???" > as I understand it is the 23-nd. But why it appears here is really > ununderstandable. Even if those bytes don't display well in your terminal, they're definitely invalid. I'm surprized they were not encoded before being reported, I'll have to check why. However I suspect they're the sames as what appears in X-FORWARDED-REQUEST. If so, you'll note that the component which builds and emits those requests also does something strange with the double "&" when there was only one in the original request. > In 1.5-dev7 version there aren't errors also. Because 1.5-dev7 did not comply with the standard, which was an error that needed to be fixed. > Here's tcpdump: > # tcpdump -A -s 2000 -n -i lo dst host xx.xx.143.35 and dst port 9610 tcpdump -A is not exploitable because it replaces unprintable chars with dots. Better use tcpdump -X instead. Also you can safely use -s0 instead of -s2000. 0 will dump the exact packet size. > I tried to add "option accept-invalid-htttp-request" to the section > default, but haproxy still gives badrequest. This is strange. I think the tcpdump -X will help us (I'll try to reproduce). It is possible there is a bug anyway. If it's more convenient to you, you can send me the cap file privately. Regards, Willy
