bugtraq - apache tomcat cookie handling problem - characters out of 0x80

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 5 Sep 2014 15:22:14 +0300
From: Elar Lang <elarlang@...il.com>
To: bugtraq@...urityfocus.com
Subject: apache tomcat cookie handling problem - characters out of 0x80 - 0xff
 causing internal server error

#####
* Title: Client-based DoS for Apache Tomcat on sending cookie with
value out of 0x80 - 0xff scope.
* Author: Elar Lang
    @elarlang
    https://www.linkedin.com/in/elarlang
* Date: 02. January 2014 / 05. September 2014

#####
* Vendor: Apache
* Product: Tomcat
* Affected versions (at least):
7.0.26
7.0.39
7.0.40

#####
* Timeline:
#1 02. January 2014 - [me > vendor] information sent to
security@...cat.apache.org
--------------------
if HTTP request to Apache Tomcat server contains some cookie and
cookie value contains character with ascii code larger than 128 result
is Error 500 - Internal Server Error.

It's good attack vector for attackers, because one XSS hole is enough
to write one cookie with value ¤ (for example), and for that browser
this site is not accessible anymore.

Versions affected (tested):
7.0.26
7.0.39
7.0.40
--------------------

#2 08. January 2014 - [vendor > me] response from Apache. Basically,
it's not their bug. Included the following line.
--------------------
The Tomcat developers do not view the scenario you describe as a
Tomcat vulnerability since the vulnerability is the initial XSS and
without that this behaviour cannot be exploited by an attacker.
--------------------

#3 10. June 2014 - [me > vendor] information and explanation, that one
XSS in SOP (Same-Origin-Policy) scope is enough to "turn off" one
client. I also asked, how to prevent against that problem.

#4 11. June 2014 - [vendor > me] Response from Apache. "From a
security perspective there is nothing to add to our previous
response."
--------------------
For details of the changes (planned and implemented) to Tomcat's
cookie parsing that may well mitigate the DoS see the dev@ list.
--------------------

#5 04. September 2014 - [me > vendor] information resent and asked how
the impact is different from
http://www.securityfocus.com/bid/67671/info

#6 05. September 2014 - [vendor > me] Response from Apache. They said,
they have nothing to add to previous comments.

#7 05. September 2014 - [me] publish.

#####
* URL: Vulnerable sites on Tomcat, for example (based on random
sources "popular sites on Tomcat"):
www.ebay.com
www.walmart.com
www.snapdeal.com
www.zillow.com
webstore.amazon.com
www.chacha.com
upware.comcast.com
www.bizrate.com
odnoklassniki.ru
store.apple.com - ex: search functionality

#####
* Description of vulnerable software:
Apache Tomcat is an open source software implementation of the Java
Servlet and JavaServer Pages technologies. The Java Servlet and
JavaServer Pages specifications are developed under the Java Community
Process. [http://tomcat.apache.org/]

* Vulnerability:
Cookies what contains at least one symbol out of range 0x80 .. 0xff,
causing Internal Server Error.

* Preconditions:
Possibility to send "Set-Cookie" command to victim (browser):
- access to program code in some site in Same-Origin-Policy scope
- one XSS vulnerability in some site in Same-Origin-Policy scope

If the victim browser has this kind of cookie, then request from
victim's browser cause Internal Server Error a'ka this victim can not
use current web page anymore (till it has the cookie)

* PoC:
Set-Cookie: tommy=ignoringcat¤;

XSS payload: document.cookie='tommy=cat¤';

#####
Status:
unknown