[NEWS] Multiple Vendor HTTP User Agent Cookie Path Traversal Issue

• Previous message: SecuriTeam: "[NEWS] PWebServer Directory Traversal Vulnerability"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 10 Mar 2004 19:37:22 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

  Multiple Vendor HTTP User Agent Cookie Path Traversal Issue
------------------------------------------------------------------------

SUMMARY

The cookie specifications detail a path argument that can be used to
restrict the areas of a host that will be exposed to a cookie. By using
standard traversal techniques this functionality can be subverted,
potentially exposing the cookie to scrutiny and use in further attacks.

DETAILS

Analysis:
The cookie standard is formally defined in RFC2965 (
<http://www.faqs.org/rfcs/rfc2965.html>
http://www.faqs.org/rfcs/rfc2965.html). This makes reference to the
optional path argument that allows a cookie originator to specify "the
subset of URLs on the origin server to which this cookie applies".

Many of the user agents appear to function by simply string matching the
initial part of the requested URL, so by using a combination of traversal
and standard encoding techniques the path restriction functionality can be
subverted.

Where this oversight becomes useful is in conducting attacks against the
session cookies of an application that does not suffer from any
exploitable validation flaws, but that shares the same server environment
with one that does.

It is worth acknowledging that whilst many client applications still
suffer from "same origin" issues then this is something of a moot point
anyway.

Proof of concept:
This proof of concept is known to work with the current releases of the
major browsers.

For this example we shall imagine that our secure application shares a
host with some sample files that were installed at the same time as the
web server. Obviously, this would never happen in a live production
environment (pauses to insert tongue firmly in cheek).

The secure application is located within the "/secure" folder and sets the
cookie path argument to "/secure" which is intended to restrict the cookie
information from being exposed elsewhere on the same host.

The attacker knows that the secure application has no useable
vulnerabilities in itself and can also see that the cookie that it sets
has the path restricted. They also know that the sample files have an
exploitable XSS flaw that would give them access to the all-important
session cookies (if they can get a valid user to access it; a completely
different problem to solve).

A lot of browsers will make a URI canonical before passing it to the
target server, resolving any redundant directory traversal prior to
dispatch. By using an encoded URL the attacker can defeat this
functionality, bypass the path restriction intended by the originator and
get the valid users browser to expose the session cookie to the sample
application:

  http://host/secure/%2e%2e/sample/insecure.cgi?xss=>

Recommendations:
The cookie path functionality of the affected user agents should be
revised to ensure that they work as intended and cannot be bypassed by
traversal and encoding techniques.

Many of the vendors involved have silently patched this issue in product
releases made after July 2003. Check with the individual vendor for
additional information.

CVE:
The Common Vulnerabilities and Exposures (CVE) project has assigned
multiple names to this issue:

CAN-2003-0513 Microsoft Internet Explorer cookie path traversal issue
CAN-2003-0514 Apple Safari cookie path traversal issue
CAN-2003-0592 KDE Konqueror cookie path traversal issue
CAN-2003-0593 Opera cookie path traversal issue
CAN-2003-0594 Mozilla cookie path traversal issue

Disclosure timeline:
Discovered: 08.07.03
Vendors notified: 12.07.03 - 18.07.03
RFC2965 authors notified: 29.07.03
CERT/CC notified: 20.08.03
Uncoordinated Opera release: 05.09.03
NISCC notified: 24.10.03
Document released: 10.03.04

ADDITIONAL INFORMATION

The information has been provided by <mailto:martin.oneal@corsaire.com>
Martin O'Neal.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: SecuriTeam: "[NEWS] PWebServer Directory Traversal Vulnerability"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]