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