You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/05/27 14:46:43 UTC
[SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
CVE-2014-0097 Information Disclosure
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
- Apache Tomcat 8.0.0-RC1 to 8.0.3
- Apache Tomcat 7.0.0 to 7.0.52
- Apache Tomcat 6.0.0 to 6.0.39
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.
Mitigation:
Users of affected versions should apply one of the following mitigations
- Upgrade to Apache Tomcat 8.0.5 or later
(8.0.4 contains the fix but was not released)
- Upgrade to Apache Tomcat 7.0.53 or later
- Upgrade to Apache Tomcat 6.0.41 or later
(6.0.40 contains the fix but was not released)
Credit:
A test case that demonstrated the parsing bug was sent to the Tomcat
security team but no context was provided. The security implications
were identified by the Tomcat security team .
References:
[1] http://tomcat.apache.org/security-8.html
[2] http://tomcat.apache.org/security-7.html
[3] http://tomcat.apache.org/security-6.html
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
CORRECTION: This is CVE-2014-0099 *NOT* -0097
Apologies for the typo
On 27/05/2014 13:46, Mark Thomas wrote:
> CVE-2014-0099 Information Disclosure
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> - Apache Tomcat 8.0.0-RC1 to 8.0.3
> - Apache Tomcat 7.0.0 to 7.0.52
> - Apache Tomcat 6.0.0 to 6.0.39
>
> 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.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - Upgrade to Apache Tomcat 8.0.5 or later
> (8.0.4 contains the fix but was not released)
> - Upgrade to Apache Tomcat 7.0.53 or later
> - Upgrade to Apache Tomcat 6.0.41 or later
> (6.0.40 contains the fix but was not released)
>
> Credit:
> A test case that demonstrated the parsing bug was sent to the Tomcat
> security team but no context was provided. The security implications
> were identified by the Tomcat security team .
>
> References:
> [1] http://tomcat.apache.org/security-8.html
> [2] http://tomcat.apache.org/security-7.html
> [3] http://tomcat.apache.org/security-6.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: security-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
On 5/27/14, 8:46 AM, Mark Thomas wrote:
> CVE-2014-0097 Information Disclosure
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache
> Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39
>
> 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.
>
> Mitigation: Users of affected versions should apply one of the
> following mitigations - Upgrade to Apache Tomcat 8.0.5 or later
> (8.0.4 contains the fix but was not released) - Upgrade to Apache
> Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later
> (6.0.40 contains the fix but was not released)
Alternate mitigation (for httpd):
SetEnvIf "Content-Length" ",{10,}" no-jk=1
You can use any reasonable number in place of "10". Note that a 1GiB
Content-Length would be "1073741824" which is 10 characters, so it
would be rejected.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThN0pAAoJEBzwKT+lPKRYsp0QAMI6viexulYScNMfgExgxxmw
IU/2GzWBxkATN1OEtRXMObqG+ODC2QkCIDNP4Dsznvi8iwlkzr+q/DwqdbisB0xS
gF2JSuNCFdVPzR/KmmgFVzMNj3SmmmIwXp9hQHOBr1H6mTd/om+DcZ2w5sRozqeG
0bC/co5ZddZIV+ObY89qBHYNpt6zLL4PC2Bz7azrB+0X27G5pyh252cFi3IiGzq6
HujnoIMqf8ddz2MTthUz0VFNTVnnZRVTIB/0hX+2sKe/9TcjEfuPxIRnrTtmVoYE
aN62jdL+Ezt34GL8MwbZRDLBgBPNCS4V8pKGwiZpq7qtAlpWJNv/IpwkTzTyHkSm
oeAZSElvQYeVD1tqRYubPXMhvmscYnntbEjBSi1QdSwrvUr1ZIq1z6xuO4hDURx7
Td/B+axvPS3AVOXTk49gxLE/BG+//ly93svfTFRELDTcOsv5am4W4jGHjMRVcDhy
TmJwXUPIpvy8kqmmzZ5hH3hc26Zj47QQxwZeGyFIAjKMklHE0StBr3qtmasEr5tv
H+lWUrBIUXD0i87qzcPNSbRMSTsQvQ27CqPUEslF2o5N/QF/CVc0aQrmcsgil790
b67hpOJ6q3qwTzeCs927qj9+GAC435OHAu9YyjBYHoYReNdVurYP00uMKg+7zL5t
3XDkBXjrLm/FTWpmLBPV
=qbxd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
CORRECTION: This is CVE-2014-0099 *NOT* -0097
Apologies for the typo
On 27/05/2014 13:46, Mark Thomas wrote:
> CVE-2014-0099 Information Disclosure
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> - Apache Tomcat 8.0.0-RC1 to 8.0.3
> - Apache Tomcat 7.0.0 to 7.0.52
> - Apache Tomcat 6.0.0 to 6.0.39
>
> 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.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - Upgrade to Apache Tomcat 8.0.5 or later
> (8.0.4 contains the fix but was not released)
> - Upgrade to Apache Tomcat 7.0.53 or later
> - Upgrade to Apache Tomcat 6.0.41 or later
> (6.0.40 contains the fix but was not released)
>
> Credit:
> A test case that demonstrated the parsing bug was sent to the Tomcat
> security team but no context was provided. The security implications
> were identified by the Tomcat security team .
>
> References:
> [1] http://tomcat.apache.org/security-8.html
> [2] http://tomcat.apache.org/security-7.html
> [3] http://tomcat.apache.org/security-6.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: security-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThNhhAAoJEBzwKT+lPKRY7pgP/iXdPHcHbUfB33CcR3cwtXsQ
d6poIuOtPWzNqPJrfGvu20A2L5TRtw9AHx8TQCL6tGY3BuDOgKSOxEbtWGr0E8Gq
b1ipr8oc6ZrFvffiHfgew1QPLY4/FJC7rSjf/koV6iRsYLciGmN/DxRlmbsgqUj2
uYQtv6PhYTKOwijQ/rGxb3GjmqMP5yiXTz3YAkWb/2adHg3+luXNNxpr0Ar1snFY
OZLipS6YTmyQQl5QFgATuK4KbWQ2XcgRmtM8ldbKMWO2DMbyEGWOq3zzC8pVIJ+x
WdsOebnj2nGaXxewi5RtJ6M/HiJdE4mIv6vT5E9O0TJJFwgl+l5i30AkSSGyr3CM
t5oZQ76Zu8TrHXev7WDOBrAAuxacngbafxVbKimBpJcXnoeh07yOThXug71TReAx
oUncKGvCHYG7rGMYOJ2Cshs+IhhqJCTRiff6InzkFKSl1E+FKM+iVoZXGv0JP8KP
zPe18lWjbKTMd68x24HFNrylyVPEbc2MyG4cUJQ5Dw+r9NCKxzha/K+yxh6gAPQl
KAiHyXeJfkGmr7uD4bhyywcjWi05QKLZkyQlvhanQ1N3442luJSj+KLTkybPA0Nx
FZBlGdYF9ZGWNiK1qkvvwZqH/TKFxNOzl0yaAF7It7rnEsCKJs8DDX/QK5QuaUAX
SBZqArXqomy3tWJ29VnI
=fZQ0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
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.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 27/05/2014 15:12, Konstantin Preißer wrote:
>> Hi André,
>>
>>> -----Original Message-----
>>> From: André Warnier [mailto:aw@ice-sa.com]
>>> Sent: Tuesday, May 27, 2014 3:06 PM
>>>
>>> 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.
>>> If someone feels like explaining..
>> The fix for this issue also made me a bit curious (I don't know the background of the issue).
>>
>> The old code for parsing the Content-Length header looked like this:
>>
>> long n = c - '0';
>> long m;
>>
>> while (--len > 0) {
>> if (!isDigit(c = b[off++])) {
>> throw new NumberFormatException();
>> }
>> m = n * 10 + c - '0';
>>
>> if (m < n) {
>> // Overflow
>> throw new NumberFormatException();
>> } else {
>> n = m;
>> }
>> }
>>
>> Where "b" is a byte-array containing ASCII decimal chars.
>>
>> The code parses a decimal number like "123" by multiplying the current number (e.g. 12) by 10 (=120), then adding the next character (=123).
>>
>> To check for an overflow, it checks if the "new" number is lower than the old one. Usually, when making a simple addition with positive numbers where the second one is low (0-9), this is enough as for an overflow, the first bit will go to 1, so the number is negative. E.g., when using signed bytes (8 bits):
>> 0111111b (127) + 3 = 10000010b (-126)
>>
>> However, the code above also does an multiplication by 10. For example, if the current number (signed long) is 6148914691236517205 (binary: 101010101010101010101010101010101010101010101010101010101010101b) and the next character is '3', the calculation would be:
>>
>> 101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205) * 1010b (10) =
>> 101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202)
>>
>> 101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202) + 11b (3) =
>> 101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205)
>>
>> In this case, the new number would == the old number, so the code " if (m < n)" would not detect the overflow.
>>
>> E.g., if you run following code:
>>
>> long a = 6148914691236517205L;
>> long b = a * 10 + 3;
>> System.out.println(a == b);
>>
>> it will print "true".
>>
>>
>> However, I don't know if such example is really the one that causes issues, as this number is pretty high (but I did not found how smaller numbers could cause overflows not to be detected). Maybe someone could comment on that.
>
> Yes, you need to have a content-length above Long.MAX_VALUE for problems
> to occur. That would be unusual to say the least for most (all?)
> applications in normal usage but easy for a malicious user to set.
>
> If the proxy handles the header correctly, the attacker is going to have
> to send a *lot* of data to get this to work. Where things would get
> interesting is if the proxy and Tomcat both had parsing issues but ended
> up with different values. That would make request smuggling a lot easier.
>
> Something else to consider. If an attacker can trigger this
> "request/response offset" then any subsequent requests they make could
> receive responses that contain data from other users. Even if they can't
> control what that data is, that is still information disclosure.
>
Just for the sake of it, I don't really see how that last scenario could come to pass
though. Let's say that user A sends such a malicious request to the front-end, and the
front-end interprets it correctly as one request, and passes it on to tomcat over a
connector connection. Then Tomcat misinterprets this as being several requests in a row,
and distributes them to several threads, to process and return responses, onto that same
connector connection. And then, the first Tomcat thread to be finished, would return a
response to the first part of that request. And then the front-end would think that this
is the response to the original request, return it to the first (malicious) user, and that
would be that for this request (for the front-end).
If in the meantime the front-end receives another request, and it could (at the end of the
first request) send this other request to Tomcat, using the same connection.
And then the front-end may receive the response to Tomcat's "second request" (which in
fact was a second part of the first), but it would think that it was the response to the
second request, and forward it to the "wrong" user.
So now the 2 systems are out of sync. Tomcat keeps on processing parts of the first
malicious request as being separate requests, and the responses to such requests are being
sent back as responses to subsequent genuine requests arriving at the front-end, instead
of being the real responses to those genuine subsequent requests.
And the extent of this out-of-sync situation is determined by how many "hidden requests"
that first malicious request managed to sneak past.
So it is all very confusing for the genuine users who get nonsensical ansers to their
genuine requests. But I do not see how the first malicious user could start getting the
responses of other user's genuine requests. "His" original request is already
long-answered, so he would not get any additional responses.
Ultimately, the front-end will end up receiving more responses from Tomcat, than the
number of requests it has received and has sent to Tomcat. But it should then discard
these additional responses, since it doesn't have any pending request to satisfy with them.
Or am I missing something ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/27/14, 10:32 AM, Mark Thomas wrote:
> On 27/05/2014 15:12, Konstantin Preißer wrote:
>> Hi André,
>>
>>> -----Original Message----- From: André Warnier
>>> [mailto:aw@ice-sa.com] Sent: Tuesday, May 27, 2014 3:06 PM
>>>
>>> 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. If someone feels like explaining..
>>
>> The fix for this issue also made me a bit curious (I don't know
>> the background of the issue).
>>
>> The old code for parsing the Content-Length header looked like
>> this:
>>
>> long n = c - '0'; long m;
>>
>> while (--len > 0) { if (!isDigit(c = b[off++])) { throw new
>> NumberFormatException(); } m = n * 10 + c - '0';
>>
>> if (m < n) { // Overflow throw new NumberFormatException(); }
>> else { n = m; } }
>>
>> Where "b" is a byte-array containing ASCII decimal chars.
>>
>> The code parses a decimal number like "123" by multiplying the
>> current number (e.g. 12) by 10 (=120), then adding the next
>> character (=123).
>>
>> To check for an overflow, it checks if the "new" number is lower
>> than the old one. Usually, when making a simple addition with
>> positive numbers where the second one is low (0-9), this is
>> enough as for an overflow, the first bit will go to 1, so the
>> number is negative. E.g., when using signed bytes (8 bits):
>> 0111111b (127) + 3 = 10000010b (-126)
>>
>> However, the code above also does an multiplication by 10. For
>> example, if the current number (signed long) is
>> 6148914691236517205 (binary:
>> 101010101010101010101010101010101010101010101010101010101010101b)
>> and the next character is '3', the calculation would be:
>>
>> 101010101010101010101010101010101010101010101010101010101010101b
>> (6148914691236517205) * 1010b (10) =
>> 101010101010101010101010101010101010101010101010101010101010010b
>> (6148914691236517202)
>>
>> 101010101010101010101010101010101010101010101010101010101010010b
>> (6148914691236517202) + 11b (3) =
>> 101010101010101010101010101010101010101010101010101010101010101b
>> (6148914691236517205)
>>
>> In this case, the new number would == the old number, so the code
>> " if (m < n)" would not detect the overflow.
>>
>> E.g., if you run following code:
>>
>> long a = 6148914691236517205L; long b = a * 10 + 3;
>> System.out.println(a == b);
>>
>> it will print "true".
>>
>>
>> However, I don't know if such example is really the one that
>> causes issues, as this number is pretty high (but I did not found
>> how smaller numbers could cause overflows not to be detected).
>> Maybe someone could comment on that.
>
> Yes, you need to have a content-length above Long.MAX_VALUE for
> problems to occur. That would be unusual to say the least for most
> (all?) applications in normal usage but easy for a malicious user
> to set.
>
> If the proxy handles the header correctly, the attacker is going to
> have to send a *lot* of data to get this to work. Where things
> would get interesting is if the proxy and Tomcat both had parsing
> issues but ended up with different values. That would make request
> smuggling a lot easier.
>
> Something else to consider. If an attacker can trigger this
> "request/response offset" then any subsequent requests they make
> could receive responses that contain data from other users. Even if
> they can't control what that data is, that is still information
> disclosure.
It's worth pointing out that one of the mitigations of this
vulnerability is to configure the proxy to reject very large values
for Content-Length.
For instance, we don't expect any file uploads, etc. larger than a few
MB. So for httpd, we could do something like this:
SetEnvIf "Content-Type" ".{10,}" no-jk=1
This will refuse to send any requests via mod_jk if they have
Content-Type headers whose values are 10 or more characters. We do the
same thing for Accept-Language for a bug that has been long-since
fixed I think.
It's probably worth publishing that mitigation since it's easier to do
than upgrading Tomcat if it's an emergency.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThNtUAAoJEBzwKT+lPKRY75AP/iyC/mb1S+JgVkcWid/Xqsn5
RfSPLMmT5G+yVSBiWRa9P8Rp3Tg1FE63aQtr0ybLCwh/ds4RXapbkNQATyXeAwgf
viwLpE7iuzS4SQs18zSh60jaEdKJh9MrCrc2YL5gTq2crcJMz9s8PKOmtZQ/kY1e
T71BlvPef5GHkzjWMfVEodMubtOWnp346COeFtDdJpi8zzJ3/Zh9YBLBAXW+aqNh
8qxq0SEZchrgiFmfuP83A59JOzHm8xz3QOf2SjHEitYE5kOo3t+zyTIOZRAlh0Ka
poegWmpEKd94/GiyxkH5OfbqwDjFdg8tb/acm+4PX6aZiXyx5K3Ri4pIji64llEw
jJCx6RSNgAkgjt8206TGV09tkCrtym7sACyQ6afl8kQQlPWVPitzpk/4ITzwtoRR
WieZc4yAsp03sT85Ti3xwUstvhANcHXn0ltc6JNH3mvOHfLnTScKoJA7s6nLyDuN
NTKhNHc9Rm1hHz0Kpuf/AHl9jgD1hFB8qpLMl0P570+yzALeiM4So+46/6dfTqtR
7N+Ngh3TElIpuMPkzXHg5KQNi3Nz4tKA9Gaytg70dDBV0u0GVTVEwBD9UIWo72oT
/BNI0UUIC5Xg5ER/JIgwPErmg6RFlTNE+rCUrxMzreFjVfLq1YtUNL0OBbqxD9/B
J/79gZcvBPsvGvGlIU+D
=Osrg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Mark,
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Tuesday, May 27, 2014 4:33 PM
<snip>
> Yes, you need to have a content-length above Long.MAX_VALUE for
> problems
> to occur. That would be unusual to say the least for most (all?)
> applications in normal usage but easy for a malicious user to set.
>
> If the proxy handles the header correctly, the attacker is going to have
> to send a *lot* of data to get this to work. Where things would get
> interesting is if the proxy and Tomcat both had parsing issues but ended
> up with different values. That would make request smuggling a lot easier.
>
> Something else to consider. If an attacker can trigger this
> "request/response offset" then any subsequent requests they make could
> receive responses that contain data from other users. Even if they can't
> control what that data is, that is still information disclosure.
OK, thanks for the clarification!
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
On 27/05/2014 15:12, Konstantin Preißer wrote:
> Hi André,
>
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Tuesday, May 27, 2014 3:06 PM
>>
>> 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.
>> If someone feels like explaining..
>
> The fix for this issue also made me a bit curious (I don't know the background of the issue).
>
> The old code for parsing the Content-Length header looked like this:
>
> long n = c - '0';
> long m;
>
> while (--len > 0) {
> if (!isDigit(c = b[off++])) {
> throw new NumberFormatException();
> }
> m = n * 10 + c - '0';
>
> if (m < n) {
> // Overflow
> throw new NumberFormatException();
> } else {
> n = m;
> }
> }
>
> Where "b" is a byte-array containing ASCII decimal chars.
>
> The code parses a decimal number like "123" by multiplying the current number (e.g. 12) by 10 (=120), then adding the next character (=123).
>
> To check for an overflow, it checks if the "new" number is lower than the old one. Usually, when making a simple addition with positive numbers where the second one is low (0-9), this is enough as for an overflow, the first bit will go to 1, so the number is negative. E.g., when using signed bytes (8 bits):
> 0111111b (127) + 3 = 10000010b (-126)
>
> However, the code above also does an multiplication by 10. For example, if the current number (signed long) is 6148914691236517205 (binary: 101010101010101010101010101010101010101010101010101010101010101b) and the next character is '3', the calculation would be:
>
> 101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205) * 1010b (10) =
> 101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202)
>
> 101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202) + 11b (3) =
> 101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205)
>
> In this case, the new number would == the old number, so the code " if (m < n)" would not detect the overflow.
>
> E.g., if you run following code:
>
> long a = 6148914691236517205L;
> long b = a * 10 + 3;
> System.out.println(a == b);
>
> it will print "true".
>
>
> However, I don't know if such example is really the one that causes issues, as this number is pretty high (but I did not found how smaller numbers could cause overflows not to be detected). Maybe someone could comment on that.
Yes, you need to have a content-length above Long.MAX_VALUE for problems
to occur. That would be unusual to say the least for most (all?)
applications in normal usage but easy for a malicious user to set.
If the proxy handles the header correctly, the attacker is going to have
to send a *lot* of data to get this to work. Where things would get
interesting is if the proxy and Tomcat both had parsing issues but ended
up with different values. That would make request smuggling a lot easier.
Something else to consider. If an attacker can trigger this
"request/response offset" then any subsequent requests they make could
receive responses that contain data from other users. Even if they can't
control what that data is, that is still information disclosure.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 5/27/14, 10:12 AM, Konstantin Preißer wrote:
> Hi André,
>
>> -----Original Message----- From: André Warnier
>> [mailto:aw@ice-sa.com] Sent: Tuesday, May 27, 2014 3:06 PM
>>
>> Mark Thomas wrote:
>>> CVE-2014-0097 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. If someone feels like explaining..
>
> The fix for this issue also made me a bit curious (I don't know the
> background of the issue).
>
> The old code for parsing the Content-Length header looked like
> this:
>
> long n = c - '0'; long m;
>
> while (--len > 0) { if (!isDigit(c = b[off++])) { throw new
> NumberFormatException(); } m = n * 10 + c - '0';
>
> if (m < n) { // Overflow throw new NumberFormatException(); } else
> { n = m; } }
>
> Where "b" is a byte-array containing ASCII decimal chars.
>
> The code parses a decimal number like "123" by multiplying the
> current number (e.g. 12) by 10 (=120), then adding the next
> character (=123).
>
> To check for an overflow, it checks if the "new" number is lower
> than the old one. Usually, when making a simple addition with
> positive numbers where the second one is low (0-9), this is enough
> as for an overflow, the first bit will go to 1, so the number is
> negative. E.g., when using signed bytes (8 bits): 0111111b (127) +
> 3 = 10000010b (-126)
>
> However, the code above also does an multiplication by 10. For
> example, if the current number (signed long) is 6148914691236517205
> (binary:
> 101010101010101010101010101010101010101010101010101010101010101b)
> and the next character is '3', the calculation would be:
>
> 101010101010101010101010101010101010101010101010101010101010101b
> (6148914691236517205) * 1010b (10) =
> 101010101010101010101010101010101010101010101010101010101010010b
> (6148914691236517202)
Honestly, I was dumbfounded to see this in action. I've never studied
signed multiplication before. I'll have to read a lot more about this.
> 101010101010101010101010101010101010101010101010101010101010010b
> (6148914691236517202) + 11b (3) =
> 101010101010101010101010101010101010101010101010101010101010101b
> (6148914691236517205)
>
> In this case, the new number would == the old number, so the code "
> if (m < n)" would not detect the overflow.
Crazy.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThNvAAAoJEBzwKT+lPKRYr5gP/RBQRQ2ghYSjX7GIwOpRB20R
OGMfB7ACPfsXgp/V2syqLkNSiou0xKZvdffxkD4H90wmlTvWB9PZ7ZH6q87d6hZi
6Uq2CITabYVG9aMHeVcQ7ZUOIelGJkFCwRd9c1TtuYeuNeDZ+eGGSeU/ji9AVP/S
+f0/5+EnqsWgnAcdJ7FRzN1x6cBd80x9YqCY0hVkpgzeEjdTe++DaK10TWWVAPDb
Uk+cGKmdkAivsNiyqQmHvM7chR4UZwbefyH/gHDLdISbNThq2Gg64dPVPqjBydoS
2eEYv4DFbSwdBijQseWEEi014EO6m54kymYzV4wlnYwsdntMrZIPDMrkkrGqpn8Z
S8miQ0ezGV6HI1n/iMtlAX4uCG4BPxg2xdsDlrSl/riBBgwqhiqi3BFBM0qmDdFv
1hUSnoMJAiQfcldWqR/1BTj0t7GC7EmP+j1Pb2gA/8GhCj2AMx4eWgf2gz6voDB/
lTG8XmvEZJZHevT+LoKv+tTPqT20U0i5ltkI2VSUdO6u1TBZUh9ofkdheRLPVWeN
D00UAFBdPQfTa2JfC8QXNFY+vEyyFmQYcZRqnEZEZU2C3pPCzoGt/+MrndsZAwjS
nb9LjiJPflYO585pS8zE/Oymvtn7ZYALx1bAAf9fexwtYOUl3Rcy1n1lwIV4QWAW
Bhsbtz5rJNLoR6LOYnwy
=HxCV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Posted by Konstantin Preißer <kp...@apache.org>.
Hi André,
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, May 27, 2014 3:06 PM
>
> Mark Thomas wrote:
> > CVE-2014-0097 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.
> If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know the background of the issue).
The old code for parsing the Content-Length header looked like this:
long n = c - '0';
long m;
while (--len > 0) {
if (!isDigit(c = b[off++])) {
throw new NumberFormatException();
}
m = n * 10 + c - '0';
if (m < n) {
// Overflow
throw new NumberFormatException();
} else {
n = m;
}
}
Where "b" is a byte-array containing ASCII decimal chars.
The code parses a decimal number like "123" by multiplying the current number (e.g. 12) by 10 (=120), then adding the next character (=123).
To check for an overflow, it checks if the "new" number is lower than the old one. Usually, when making a simple addition with positive numbers where the second one is low (0-9), this is enough as for an overflow, the first bit will go to 1, so the number is negative. E.g., when using signed bytes (8 bits):
0111111b (127) + 3 = 10000010b (-126)
However, the code above also does an multiplication by 10. For example, if the current number (signed long) is 6148914691236517205 (binary: 101010101010101010101010101010101010101010101010101010101010101b) and the next character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202)
101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205)
In this case, the new number would == the old number, so the code " if (m < n)" would not detect the overflow.
E.g., if you run following code:
long a = 6148914691236517205L;
long b = a * 10 + 3;
System.out.println(a == b);
it will print "true".
However, I don't know if such example is really the one that causes issues, as this number is pretty high (but I did not found how smaller numbers could cause overflows not to be detected). Maybe someone could comment on that.
Thanks!
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Posted by André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> CVE-2014-0097 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.
If someone feels like explaining..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
On 5/27/14, 8:46 AM, Mark Thomas wrote:
> CVE-2014-0097 Information Disclosure
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache
> Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39
>
> 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.
>
> Mitigation: Users of affected versions should apply one of the
> following mitigations - Upgrade to Apache Tomcat 8.0.5 or later
> (8.0.4 contains the fix but was not released) - Upgrade to Apache
> Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later
> (6.0.40 contains the fix but was not released)
Alternate mitigation (for httpd):
SetEnvIf "Content-Length" ",{10,}" no-jk=1
You can use any reasonable number in place of "10". Note that a 1GiB
Content-Length would be "1073741824" which is 10 characters, so it
would be rejected.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThN0pAAoJEBzwKT+lPKRYsp0QAMI6viexulYScNMfgExgxxmw
IU/2GzWBxkATN1OEtRXMObqG+ODC2QkCIDNP4Dsznvi8iwlkzr+q/DwqdbisB0xS
gF2JSuNCFdVPzR/KmmgFVzMNj3SmmmIwXp9hQHOBr1H6mTd/om+DcZ2w5sRozqeG
0bC/co5ZddZIV+ObY89qBHYNpt6zLL4PC2Bz7azrB+0X27G5pyh252cFi3IiGzq6
HujnoIMqf8ddz2MTthUz0VFNTVnnZRVTIB/0hX+2sKe/9TcjEfuPxIRnrTtmVoYE
aN62jdL+Ezt34GL8MwbZRDLBgBPNCS4V8pKGwiZpq7qtAlpWJNv/IpwkTzTyHkSm
oeAZSElvQYeVD1tqRYubPXMhvmscYnntbEjBSi1QdSwrvUr1ZIq1z6xuO4hDURx7
Td/B+axvPS3AVOXTk49gxLE/BG+//ly93svfTFRELDTcOsv5am4W4jGHjMRVcDhy
TmJwXUPIpvy8kqmmzZ5hH3hc26Zj47QQxwZeGyFIAjKMklHE0StBr3qtmasEr5tv
H+lWUrBIUXD0i87qzcPNSbRMSTsQvQ27CqPUEslF2o5N/QF/CVc0aQrmcsgil790
b67hpOJ6q3qwTzeCs927qj9+GAC435OHAu9YyjBYHoYReNdVurYP00uMKg+7zL5t
3XDkBXjrLm/FTWpmLBPV
=qbxd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Posted by Mark Thomas <ma...@apache.org>.
CORRECTION: This is CVE-2014-0099 *NOT* -0097
Apologies for the typo
On 27/05/2014 13:46, Mark Thomas wrote:
> CVE-2014-0099 Information Disclosure
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> - Apache Tomcat 8.0.0-RC1 to 8.0.3
> - Apache Tomcat 7.0.0 to 7.0.52
> - Apache Tomcat 6.0.0 to 6.0.39
>
> 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.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - Upgrade to Apache Tomcat 8.0.5 or later
> (8.0.4 contains the fix but was not released)
> - Upgrade to Apache Tomcat 7.0.53 or later
> - Upgrade to Apache Tomcat 6.0.41 or later
> (6.0.40 contains the fix but was not released)
>
> Credit:
> A test case that demonstrated the parsing bug was sent to the Tomcat
> security team but no context was provided. The security implications
> were identified by the Tomcat security team .
>
> References:
> [1] http://tomcat.apache.org/security-8.html
> [2] http://tomcat.apache.org/security-7.html
> [3] http://tomcat.apache.org/security-6.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: security-help@tomcat.apache.org
>