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..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
