You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2014/05/27 21:41:55 UTC

Re: [OT] [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure

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?
> 

Only from Belgian waffles though.
Example :
delicious
dɪˈlɪʃəs/
adjective

     highly pleasant to the taste.
     "delicious Belgian waffles" (*)
     synonyms:	mouth-watering, appetizing, tasty, flavoursome, flavourful, delectable, 
toothsome, inviting, very enjoyable, very palatable;
     succulent, luscious, rich, sweet;
     savoury, piquant;
     informalscrumptious, delish, scrummy, yummy, yum-yum;
     informalmoreish;
     informalfinger-licking, nummy;
     literaryambrosial;
     rareambrosian, nectareous, nectarean, flavorous, sapid
         synonyms:	delightful, exquisite, delectable, lovely, pleasurable, extremely 
pleasant/enjoyable;
         informalglorious, heavenly, divine


(*) an obviously tautological expression, since Belgian waffles are delicious by definition

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org