[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [Full-disclosure] Chrome and Safari users open to stealth HTML5
From:       Lavakumar Kuppan <lava () andlabs ! org>
Date:       2010-06-29 6:33:20
Message-ID: AANLkTimMTMxZDwfIjilj4njk2eBcAvaWwt2LQHqp5n7h () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Mike,

That interpretation is accurate.

Dan,

It is not possible to create caches for HTTPS resources over HTTP.
However by caching root pages of the site's HTTP equivalent we can attack
the user before redirecting to HTTPS.
Similar to SSLstrip.

I probably didnt explain this well in the mail, sorry about that.

Cheers,
Lava

On Tue, Jun 29, 2010 at 6:23 AM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > On unsecured networks, attackers could stealthily
> > create malicious Application Caches in the browser of victims for even
> HTTPS
> > sites. It has always been possible to poison the browser cache and
> > compromise the victim's account for HTTP based sites.
> > With HTML5 Application Cache, it is possible to poison the cache of even
> > HTTPS sites.
> > ==
> >
> > Is it agreed that if the above is true -- meaning, separation doesn't
> > actually exist -- then there's a bug?
>
> My understanding is that this refers to the ability to poison
> http://www.mybank.com - which may be the default destination for a
> good percentage of users - even if the only function of this page is
> to redirect directly to https://www.mybank.com.
>
> There should be no ability to use cache manifests delivered over http
> to inject content into the https origin, or at least I hope so.
>
> /mz
>
>

[Attachment #5 (text/html)]

<div>Mike,</div><div><br></div>That interpretation is accurate.<div><br></div><div>Dan, \
</div><div><br></div><div><div>It is not possible to create caches for HTTPS resources over \
HTTP.</div><div>However by caching root pages of the site&#39;s HTTP equivalent we can attack \
the user before redirecting to HTTPS.</div> <div>Similar to \
SSLstrip.</div><div><br></div><div>I probably didnt explain this well in the mail, sorry about \
that.</div></div><div><br></div><div>Cheers,</div><div>Lava</div><div><br><div \
class="gmail_quote">On Tue, Jun 29, 2010 at 6:23 AM, Michal Zalewski <span dir="ltr">&lt;<a \
href="mailto:lcamtuf@coredump.cx">lcamtuf@coredump.cx</a>&gt;</span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div \
class="im">&gt; On unsecured networks, attackers could stealthily<br> &gt; create malicious \
Application Caches in the browser of victims for even HTTPS<br> &gt; sites. It has always been \
possible to poison the browser cache and<br> &gt; compromise the victim&#39;s account for HTTP \
based sites.<br> &gt; With HTML5 Application Cache, it is possible to poison the cache of \
even<br> &gt; HTTPS sites.<br>
&gt; ==<br>
&gt;<br>
&gt; Is it agreed that if the above is true -- meaning, separation doesn&#39;t<br>
&gt; actually exist -- then there&#39;s a bug?<br>
<br>
</div>My understanding is that this refers to the ability to poison<br>
<a href="http://www.mybank.com" target="_blank">http://www.mybank.com</a> - which may be the \
default destination for a<br> good percentage of users - even if the only function of this page \
is<br> to redirect directly to <a href="https://www.mybank.com" \
target="_blank">https://www.mybank.com</a>.<br> <br>
There should be no ability to use cache manifests delivered over http<br>
to inject content into the https origin, or at least I hope so.<br>
<font color="#888888"><br>
/mz<br>
<br>
</font></blockquote></div><br></div>



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[prev in list] [next in list] [prev in thread] [next in thread]