Message-ID: <001901c48434$f9993630$1432140a@mylaptop>
Date: Tue, 17 Aug 2004 14:04:05 +0530
From: "Rohit Dube" <rohit@...tikalsolutions.com>
To: <full-disclosure@...ts.netsys.com>, <bugtraq@...urityfocus.com>
Subject: Third party cookie handling in Opera can lead to potential compromises in Servers relying on redirection

Hi,
 Opera's policy with respect to third party cookie makes it vulnerable to
session replay attacks. This was discovered 2 weeks back. Opera's response
to the same is attached. The issue and the workaround are listed below.

Opera claims to be the fastest browser on earth and has the third largest
user base.

Issue:
In case Opera privacy policy is set to refuse all third party cookies, some
servers (one is mail.yahoo.com) become susceptible to session replay
attacks. Reproduction steps, for mail.yahoo.com are:
1. set third party cookie handling to refuse all third party cookies.
2. login to your yahoo mail account.
3. sign out. 
4. Check the cookies using opera cookie manager. The cookies 'T' and 'Y' are
set to expire in 1970. 
5. Change the same to sometime in the future. 
6. In the address bar, type mail.yahoo.com, you will be in the last account
without needing username or password.

Yahoo is not maintaining a session at its end and is relying entirely on
cookies for session information. This leads to a session replay attack for
Opera users at public computers, cyber cafes etc. IE/firefox/mozilla work
fine. This can be reproduced for any network community which is relying on
cookies alone for session management across a host of its services [mail,
chat etc]

Cause:
This is so because for the domain (mail.yahoo.com) the above said two
cookies are not deleted/overwritten at logout if third party cookie handling
is set to refuse all third party cookies. According to Opera, This is so
because
"
cookies for the URL because it is considered a thirdparty
server (f533.mail.yahoo.com != yahoo.com). This is based on
the RFC 2109 (sec. 4.3.5) and RFC 2965 (sec. 3.3.6) definition
of "unverifiable transactions", which includes redirection.

RFC 2965:

  An unverifiable transaction is to a third-party host if its request-
  host U does not domain-match the reach R of the request-host O in the
  origin transaction.

  When it makes an unverifiable transaction, a user agent MUST disable
  all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
  accept any received cookies) if the transaction is to a third-party
  host.
"

So, according to Opera, it's a case of correct implementation of RFC causing
a compromise for the users. It all depends on what can be classified as
unverifiable transaction.
 	Shouldn't this still be fixed either by Yahoo or by Opera for better
security of customers?

Work arounds are several:
1. Allow third party cookies.
2. Set Opera to delete all private data at the time of closure.

Credits:
Rohit Dube.

Thanx
Rohit Dube
KritiKal Solutions Private Limited
TB1,TBIU,
Block One Extension, 
IIT Delhi,
New Delhi - 110017
India.

----The reader this message encounters not failing to understand is
cursed.----

Reply-To: "Rohit Dube" <rddube@...il.com>
From: "Rohit Dube" <rddube@...il.com>
To: <rohit@...tikalsolutions.com>
References: <opscn6pgtqd0s2l8@...l.opera.com> <opscofrs0wd0s2l8@...l.opera.com> <32a18c3704081321193289298d@...l.gmail.com> <32a18c37040815220630db89ff@...l.gmail.com> <opsctgn1vad0s2l8@...l.opera.com>
Subject: Fwd: Cookie handling in opera, third party cookies.
Date: Tue, 17 Aug 2004 11:19:31 +0530
Message-ID: <32a18c37040816224938885ad2@...l.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0015_01C48463.134FEB90"
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <opsctgn1vad0s2l8@...l.opera.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C48463.134FEB90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: bug-149095-s264@...s.opera.com <bug-149095-s264@...s.opera.com>
Date: Mon, 16 Aug 2004 10:32:15 +0200
Subject: Re: Cookie handling in opera, third party cookies.
To: rddube@...il.com

P=E5 Mon, 16 Aug 2004 10:36:16 +0530, skrev
<bug-149095-reporter@...s.opera.com>:

> I checked further, this is not a problem with yahoo.This is a case of
faulty cookie handling by Opera incase of redirects.

 This is by design, and it _is_ a problem with Yahoo,
just not an obvious one.  See below.

Since redirects are not triggered by the user, they are
treated in the same way as inline elements (img, etc.)
from other servers.

I qoute a comment from the developer for more detail:

'... the login.yahoo server will NEVER send a "delete cookie"
message because it does not know that the client have any
cookies it should delete.

And the reason it does not know is that Opera has disabled
cookies for the URL because it is considered a thirdparty
server (f533.mail.yahoo.com !=3D yahoo.com). This is based on
the RFC 2109 (sec. 4.3.5) and RFC 2965 (sec. 3.3.6) definition
of "unverifiable transactions", which includes redirection.

RFC 2965:

  An unverifiable transaction is to a third-party host if its request-
  host U does not domain-match the reach R of the request-host O in the
  origin transaction.

  When it makes an unverifiable transaction, a user agent MUST disable
  all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
  accept any received cookies) if the transaction is to a third-party
  host.

The reason it becomes a "problem" for Opera users is that we have
different (and stricter) definition of what is a thirdparty server
than MSIE (we include redirects), but considering MSN's use of a
centralized GUID server this may be understandable.

We cannot "fix" this problem without breaking our thirdparty
cookie handling.

The shared computer scenario can be avoided by the user using
"Delete Private Data" before leaving the computer.

The real problem here is that yahoo will accept any login-id
cookie it have ever set (or a reasonable approximation) even
AFTER it has told the client to delete the cookie. This means
that anyone listening in to a logged in yahoo connection and
grabs the cookies will be able to log into that user's account
without having the password.

Yahoo can solve the problem by first going to login.yahoo,
then clean up the mail.yahoo cookies afterwards.

They can further reduce the problem by securing their login
system against replay attacks, especially after the user has
logged out.'

--
Herman Robak,
Opera Software


------=_NextPart_000_0015_01C48463.134FEB90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>Fwd: Cookie handling in opera, third party cookies.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>---------- Forwarded message ----------</FONT>

<BR><FONT SIZE=3D2>From: bug-149095-s264@...s.opera.com =
&lt;bug-149095-s264@...s.opera.com&gt;</FONT>

<BR><FONT SIZE=3D2>Date: Mon, 16 Aug 2004 10:32:15 +0200</FONT>

<BR><FONT SIZE=3D2>Subject: Re: Cookie handling in opera, third party =
cookies.</FONT>

<BR><FONT SIZE=3D2>To: rddube@...il.com</FONT>
</P>

<P><FONT SIZE=3D2>P=E5 Mon, 16 Aug 2004 10:36:16 +0530, skrev =
&lt;bug-149095-reporter@...s.opera.com&gt;:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I checked further, this is not a problem with =
yahoo.This is a case of faulty cookie handling by Opera incase of =
redirects.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;This is by design, and it _is_ a problem with =
Yahoo,</FONT>

<BR><FONT SIZE=3D2>just not an obvious one.&nbsp; See below.</FONT>
</P>

<P><FONT SIZE=3D2>Since redirects are not triggered by the user, they =
are</FONT>

<BR><FONT SIZE=3D2>treated in the same way as inline elements (img, =
etc.)</FONT>

<BR><FONT SIZE=3D2>from other servers.</FONT>
</P>

<P><FONT SIZE=3D2>I qoute a comment from the developer for more =
detail:</FONT>
</P>

<P><FONT SIZE=3D2>'... the login.yahoo server will NEVER send a =
&quot;delete cookie&quot;</FONT>

<BR><FONT SIZE=3D2>message because it does not know that the client have =
any</FONT>

<BR><FONT SIZE=3D2>cookies it should delete.</FONT>
</P>

<P><FONT SIZE=3D2>And the reason it does not know is that Opera has =
disabled</FONT>

<BR><FONT SIZE=3D2>cookies for the URL because it is considered a =
thirdparty</FONT>

<BR><FONT SIZE=3D2>server (f533.mail.yahoo.com !=3D yahoo.com). This is =
based on</FONT>

<BR><FONT SIZE=3D2>the RFC 2109 (sec. 4.3.5) and RFC 2965 (sec. 3.3.6) =
definition</FONT>

<BR><FONT SIZE=3D2>of &quot;unverifiable transactions&quot;, which =
includes redirection.</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2965:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; An unverifiable transaction is to a third-party =
host if its request-</FONT>

<BR><FONT SIZE=3D2>&nbsp; host U does not domain-match the reach R of =
the request-host O in the</FONT>

<BR><FONT SIZE=3D2>&nbsp; origin transaction.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; When it makes an unverifiable transaction, a =
user agent MUST disable</FONT>

<BR><FONT SIZE=3D2>&nbsp; all cookie processing (i.e., MUST NOT send =
cookies, and MUST NOT</FONT>

<BR><FONT SIZE=3D2>&nbsp; accept any received cookies) if the =
transaction is to a third-party</FONT>

<BR><FONT SIZE=3D2>&nbsp; host.</FONT>
</P>

<P><FONT SIZE=3D2>The reason it becomes a &quot;problem&quot; for Opera =
users is that we have</FONT>

<BR><FONT SIZE=3D2>different (and stricter) definition of what is a =
thirdparty server</FONT>

<BR><FONT SIZE=3D2>than MSIE (we include redirects), but considering =
MSN's use of a</FONT>

<BR><FONT SIZE=3D2>centralized GUID server this may be =
understandable.</FONT>
</P>

<P><FONT SIZE=3D2>We cannot &quot;fix&quot; this problem without =
breaking our thirdparty</FONT>

<BR><FONT SIZE=3D2>cookie handling.</FONT>
</P>

<P><FONT SIZE=3D2>The shared computer scenario can be avoided by the =
user using</FONT>

<BR><FONT SIZE=3D2>&quot;Delete Private Data&quot; before leaving the =
computer.</FONT>
</P>

<P><FONT SIZE=3D2>The real problem here is that yahoo will accept any =
login-id</FONT>

<BR><FONT SIZE=3D2>cookie it have ever set (or a reasonable =
approximation) even</FONT>

<BR><FONT SIZE=3D2>AFTER it has told the client to delete the cookie. =
This means</FONT>

<BR><FONT SIZE=3D2>that anyone listening in to a logged in yahoo =
connection and</FONT>

<BR><FONT SIZE=3D2>grabs the cookies will be able to log into that =
user's account</FONT>

<BR><FONT SIZE=3D2>without having the password.</FONT>
</P>

<P><FONT SIZE=3D2>Yahoo can solve the problem by first going to =
login.yahoo,</FONT>

<BR><FONT SIZE=3D2>then clean up the mail.yahoo cookies =
afterwards.</FONT>
</P>

<P><FONT SIZE=3D2>They can further reduce the problem by securing their =
login</FONT>

<BR><FONT SIZE=3D2>system against replay attacks, especially after the =
user has</FONT>

<BR><FONT SIZE=3D2>logged out.'</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>

<BR><FONT SIZE=3D2>Herman Robak,</FONT>

<BR><FONT SIZE=3D2>Opera Software</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0015_01C48463.134FEB90--

Powered by blists - more mailing lists