<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><BR><FONT face="Times New Roman" size=3>-- Corsaire
Security Advisory --<BR><BR>Title: Multiple vendor HTTP user agent cookie path
traversal issue<BR>Date: 12.07.03<BR>Application: Various<BR>Environment:
Various<BR>Author: Martin O'Neal [martin.oneal@corsaire.com]<BR>Audience: Vendor
notification<BR>Reference: c030712-001<BR><BR><BR>-- Scope --<BR><BR>The aim of
this document is to clearly define a vulnerability in the <BR>cookie handling
functionality of multiple vendors HTTP user agents that <BR>would allow an
attacker to avoid the path restrictions specified by a <BR>cookie's
originator.<BR><BR><BR>-- History --<BR><BR>Discovered: 08.07.03<BR>Vendors
notified: 12.07.03 - 18.07.03<BR>RFC2965 authors notified: 29.07.03<BR>CERT/CC
notified: 20.08.03<BR>Uncoordinated Opera release: 05.09.03<BR>NISCC notified:
24.10.03<BR>Document released: 10.03.04<BR><BR><BR>-- Overview --<BR><BR>The
cookie specifications detail a path argument that can be used to <BR>restrict
the areas of a host that will be exposed to a cookie. By using <BR>standard
traversal techniques this functionality can be subverted, <BR>potentially
exposing the cookie to scrutiny and use in further attacks.<BR><BR><BR>--
Analysis --<BR><BR>The cookie standard is formally defined in RFC2965 [1]. This
makes <BR>reference to the optional path argument that allows a cookie
originator <BR>to specify "the subset of URLs on the origin server to which this
cookie <BR>applies".<BR><BR>Many of the user agents appear to function by simply
string matching the <BR>initial part of the requested URL, so by using a
combination of <BR>traversal and standard encoding techniques the path
restriction <BR>functionality can be subverted. <BR><BR>Where this oversight
becomes useful is in conducting attacks against the <BR>session cookies of an
application that does not suffer from any <BR>exploitable validation flaws, but
that shares the same server <BR>environment with one that does.<BR><BR>It is
worth acknowledging that whilst many client applications still <BR>suffer from
"same origin" issues then this is something of a moot point
<BR>anyway.<BR><BR><BR>-- Proof of concept --<BR><BR>This proof of concept is
known to work with the current releases of the <BR>major browsers.<BR><BR>For
this example we shall imagine that our secure application shares a <BR>host with
some sample files that were installed at the same time as the <BR>web server.
Obviously, this would never happen in a live production <BR>environment (pauses
to insert tongue firmly in cheek).<BR><BR>The secure application is located
within the "/secure" folder and sets <BR>the cookie path argument to "/secure"
which is intended to restrict the <BR>cookie information from being exposed
elsewhere on the same host.<BR><BR>The attacker knows that the secure
application has no useable <BR>vulnerabilities in itself and can also see that
the cookie that it sets <BR>has the path restricted. They also know that the
sample files have an <BR>exploitable XSS flaw that would give them access to the
all-important <BR>session cookies (if they can get a valid user to access it; a
completely <BR>different problem to solve).<BR><BR>A lot of browsers will make a
URI canonical before passing it to the <BR>target server, resolving any
redundant directory traversal prior to <BR>dispatch. By using an encoded URL the
attacker can defeat this <BR>functionality, bypass the path restriction intended
by the originator <BR>and get the valid users browser to expose the session
cookie to the <BR>sample application:<BR><BR> </FONT><A
href="http://host/secure/../sample/insecure.cgi?xss=<golarge"><FONT
face="Times New Roman"
size=3>http://host/secure/%2e%2e/sample/insecure.cgi?xss=<golarge</FONT></A><FONT
face="Times New Roman" size=3>><BR><BR><BR>-- Recommendations --<BR><BR>The
cookie path functionality of the affected user agents should be <BR>revised to
ensure that they work as intended and cannot be bypassed by <BR>traversal and
encoding techniques.<BR><BR>Many of the vendors involved have silently patched
this issue in product <BR>releases made after July 2003. Check with the
individual vendor for <BR>additional information.<BR><BR><BR>-- CVE
--<BR><BR>The Common Vulnerabilities and Exposures (CVE) project has assigned
<BR>multiple names to this issue:<BR><BR>CAN-2003-0513 Microsoft Internet
Explorer cookie path traversal issue<BR>CAN-2003-0514 Apple Safari cookie path
traversal issue<BR>CAN-2003-0592 KDE Konqueror cookie path traversal
issue<BR>CAN-2003-0593 Opera cookie path traversal issue<BR>CAN-2003-0594
Mozilla cookie path traversal issue<BR><BR>These are candidates for inclusion in
the CVE list, which standardises <BR>names for security problems (</FONT><A
href="http://cve.mitre.org"><FONT face="Times New Roman"
size=3>http://cve.mitre.org</FONT></A><FONT face="Times New Roman"
size=3>),<BR><BR><BR>-- References --<BR><BR>[1] </FONT><A
href="http://www.faqs.org/rfcs/rfc2965.html"><FONT face="Times New Roman"
size=3>http://www.faqs.org/rfcs/rfc2965.html</FONT></A><BR><BR><BR><FONT
face="Times New Roman" size=3>-- Revision --<BR><BR>a. Initial release.<BR>b.
Minor revision.<BR>c. Amended history section.<BR>d. Amended history
section.<BR>e. Amended recommendations section.<BR>f. Released.<BR><BR><BR>--
Distribution --<BR><BR>This security advisory may be freely distributed,
provided that it <BR>remains unaltered and in its original form. <BR><BR><BR>--
Disclaimer --<BR><BR>The information contained within this advisory is supplied
"as-is" with <BR>no warranties or guarantees of fitness of use or otherwise.
Corsaire <BR>accepts no responsibility for any damage caused by the use or
misuse of <BR>this information.<BR><BR><BR>Copyright 2003 Corsaire Limited. All
rights reserved.</FONT></FONT></DIV></BODY></HTML>