-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 5/27/14, 3:04 PM, Mark Thomas wrote: > On 27/05/2014 19:24, Christopher Schultz wrote: >> André, >> >> On 5/27/14, 10:03 AM, André Warnier wrote: >>> Mark Thomas wrote: >>>> On 27/05/2014 14:05, André Warnier wrote: >>>>> Mark Thomas wrote: >>>>>> CVE-2014-0099 Information Disclosure >>>>>> >>>>> ... >>>>> >>>>>> Description: The code used to parse the request content >>>>>> length header did not check for overflow in the result. >>>>>> This exposed a request smuggling vulnerability when >>>>>> Tomcat was located behind a reverse proxy that correctly >>>>>> processed the content length header. >>>>>> >>>>> I believe you, but I must admit that I don't really get >>>>> what the problem is, here. >>>> >>>> Sure. First of all exploiting this is not easy. >>>> >>>> The problem occurs when the content-length overflows during >>>> parsing. Tomcat ends up with a lower value for the content >>>> length than is really the case. Tomcat will, therefore, read >>>> the first part of the request (up to the length it thinks it >>>> is) and process it. Assuming keep-alive is being used, >>>> Tomcat will then process the remainder of the request as a >>>> new request and generate a response for that. >>>> >>>> Things get messy when there is a reverse proxy in the mix >>>> that correctly processes the content length. >>>> >>>> What ends up happening is this. >>>> >>>> User A sends request A to proxy. Proxy sends request A to >>>> Tomcat. Tomcat process the first part of request A and sends >>>> response A1 to the proxy. The proxy sends response A1 to >>>> user A. User B sends request B to proxy. Proxy sends request >>>> B to Tomcat (using the same connection as for request A) >>>> Tomcat processes the remainder of request A and sends >>>> response A2 to the proxy Proxy sends response A2 to user B. >>>> >>>> And you end up with all future responses on that connection >>>> going to the wrong user until (which will probably happen >>>> fairly soon) Tomcat or the proxy get to a point they realise >>>> something is wrong and close the connection. >>>> >>>> How much deliberate, targeted harm you can do depends a lot >>>> on the application. It is certainly easy to trigger response >>>> mix-up and - for example on a banking site - that would be >>>> bad even if that was all you could do. >>>> >> >>> Thank you for the limpid explanation. Yes, difficult to take >>> advantage of, but certainly confusing for user B, to get >>> something he didn't ask for.. >> >> Some of my best English vocabulary comes from Belgians. And >> waffles. > > You get English vocabulary from waffles? Of course. Don't you? ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThOIPAAoJEBzwKT+lPKRY56QQAL23kz7aDppUQQhuToKO/6vR +fYTG8Zr6tqAgeCW/e85BFGlskMol9MH6RU0m7OFiuX7r2Sphj6f4Y/N1/gcS7ho 0qAElXmfHMlb97zSufLUu4nrF3+dApcAgln/EpT29yWyPU2iaEf8mq7Tq9ZUOrcj X0fLRRPJY9pByRqW7Mt7+K8MZYowaHDMbHJvkYvb5p29pQh6ofwZ9sOtJ2SW6Rzg LxuFjwCxeIHfmlp4KZUkXP7jYSUEdv2MUpQxpuXR6oes2U0upZMzA9+utc2HsWEG nCm3qpBXWWheWmf8/rz5qm3enOL+bkWKanRTKi5as+QnQxlTDqGPsxlLMruIWF2F xBEnRI3EiSGNEccGzO+bhCvJsBXN6wr/lhuuGCZVaKN86Oyn5lkQVF6OKfonuyqi Tuz/nIZ+U4bgq6KpPkdUWXwECYKg9HXsoC5GsQkT1kpGCEl/t2qT05YnVVY9bJ/O qW9m6xIHXpqBQy+sieKSkBGprxXcKnRllCEdUuqTU+1mw8RYeKvcxw9XizrrcJW0 KCSwtkwZzlVeLbYXjbRuG2NFvC88LdD3pZHGkOfEo5TnycaC2sJrVUNbenrZ6+aQ t1E7xZJV5I7Pc2aom1j7O3g8xnKVsYd46eGMgym2ZKzKE99T1Y4fK6UXFGJLdY83 fjJd8rLzlKwBBUTaDAvL =9HjU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
