Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
-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:a...@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): 011b (127) +
> 3 = 1010b (-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Hi André,
> -Original Message-
> From: André Warnier [mailto:a...@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):
011b (127) + 3 = 1010b (-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
