[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UNIRAS Brief - 114/04 - Multiple vendor HTTP user agent cookie path traversal issue


- ----------------------------------------------------------------------------------
   UNIRAS (UK Govt CERT) Briefing Notice - 114/04 dated 10.03.04  Time: 12:00  
  UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre)
- ---------------------------------------------------------------------------------- 
  UNIRAS material is also available from its website at www.uniras.gov.uk and
         Information about NISCC is available from www.niscc.gov.uk
- ----------------------------------------------------------------------------------

> =====
> Multiple vendor HTTP user agent cookie path traversal issue
> Detail
> ======
> Corsaire (http://www.corsaire.com) have discovered a path traversal 
> vulnerability in web browser implementations of the optional cookie
> path
> parameter.  The NISCC Vulnerability Management Team has acted as the
> co-ordinator for the release of this information.
> The Corsaire advisory is included below.
> As the co-ordinator, NISCC is maintaining a Vulnerability Advisory
> Notice
> at http://www.uniras.gov.uk/vuls/2004/180865/index.htm.  As further
> information becomes available, including vendor impact statements,  
> this web
> page will be updated.
> Please note that revisions to the web page will not be notified by
> email.
> ----------------------------------------------------------------------
> -
> ----
> -- Corsaire Security Advisory --
> Title: Multiple vendor HTTP user agent cookie path traversal issue
> Date: 12.07.03
> Application: Various
> Environment: Various
> Author: Martin O'Neal [martin.oneal@xxxxxxxxxxxx]
> Audience: Vendor notification
> Reference: c030712-001
> -- Scope --
> The aim of this document is to clearly define a vulnerability in the 
> cookie handling functionality of multiple vendors HTTP user agents 
> that would allow an attacker to avoid the path restrictions specified 
> by a cookie's originator.
> -- History --
> 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: ** unreleased **
> -- Overview --
> 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.
> -- Analysis --
> The cookie standard is formally defined in RFC2965 [1]. 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=<golarge>
> -- 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-0592  KDE Konqueror cookie path traversal issue
> CAN-2003-0594  Mozilla cookie path traversal issue
> These are candidates for inclusion in the CVE list, which standardises
> names for security problems (http://cve.mitre.org),
> -- References --
> [1] http://www.faqs.org/rfcs/rfc2965.html
> -- Revision --
> a. Initial release.
> b. Minor revision.
> c. Amended history section.
> d. Amended history section.
> e. Amended recommendations section.
> -- Distribution --
> This security advisory may be freely distributed, provided that it
> remains unaltered and in its original form.
> -- Disclaimer --
> The information contained within this advisory is supplied "as-is" with
> no warranties or guarantees of fitness of use or otherwise. Corsaire
> accepts no responsibility for any damage caused by the use or misuse of
> this information.
> Copyright 2003 Corsaire Limited. All rights reserved.

National  Infrastructure Security Coordination Centre (NISCC):

Protecting  the Critical National Infrastructure from Electronic Attack



This email and any files  transmitted with it are private and intended  
solely for the use of the  individual or entity to whom they are  
addressed. If you have received this email in error please return it to  
the address it came from telling them it  is not for you and then  
delete it from your system.    This email message has been swept for  
computer  viruses.
- ----------------------------------------------------------------------------------

For additional information or assistance, please contact the HELP Desk by 
telephone or Not Protectively Marked information may be sent via 
EMail to: uniras@xxxxxxxxxxxx

Office Hours:
Mon - Fri: 08:30 - 17:00 Hrs
Tel: +44 (0) 20 7821 1330 Ext 4511
Fax: +44 (0) 20 7821 1686

Outside of Office Hours:
On Call Duty Officer:
Tel: +44 (0) 20 7821 1330 and follow the prompts

- ----------------------------------------------------------------------------------
UNIRAS wishes to acknowledge the contributions of Corsaire/NISCC for the information 
contained in this Briefing. 
- ----------------------------------------------------------------------------------
This Briefing contains the information released by the original author. Some 
of the information may have changed since it was released. If the vulnerability 
affects you, it may be prudent to retrieve the advisory from the canonical site 
to ensure that you receive the most current information concerning that problem.

Reference to any specific commercial product, process, or service by trade 
name, trademark manufacturer, or otherwise, does not constitute or imply 
its endorsement, recommendation, or favouring by UNIRAS or NISCC.  The views 
and opinions of authors expressed within this notice shall not be used for 
advertising or product endorsement purposes.

Neither UNIRAS or NISCC shall also accept responsibility for any errors 
or omissions contained within this briefing notice. In particular, they shall 
not be liable for any loss or damage whatsoever, arising from or in connection 
with the usage of information contained within this notice.

UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST) 
and has contacts with other international Incident Response Teams (IRTs) in 
order to foster cooperation and coordination in incident prevention, to prompt 
rapid reaction to incidents, and to promote information sharing amongst its 
members and the community at large. 
- ----------------------------------------------------------------------------------
<End of UNIRAS Briefing>

Version: PGP 8.0