full-disclosure - Re: Google / GMail bug, all accounts vulnerable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 12 Dec 2007 22:33:04 -0800
From: coderman <coderman@...il.com>
To: steven@...urityzone.org
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Google / GMail bug, all accounts vulnerable

On Dec 12, 2007 1:27 PM, Steven Adair <steven@...urityzone.org> wrote:
> ... if you simply
> had a 302 or mod_rewrite rule for any image that you actually had written
> into the source of your page, you could achieve the same result.

no, that would only trigger a request when the page is loaded.  a
refresh on the page is likely to get filtered, but that works too.
(and was used to implement an attack against Tor clients without entry
guards to good effect, for example.)

> Maybe the favicon.ico method is slightly transparent to the user as it's
> not present when you view the source.

the key difference of the favicon method (on fetchy ffoxes) is not
just the source, but the frequent repeated requests triggered by the
presence of a non-cached favicon.  this is a versatile vector, as a
tainted favicon need only be viewable (not actually on that page, in
tabs, in bookmarks, etc) to trigger the requests.

> Explain to me what I am missing here.

perhaps you were expecting remote r00t in openbsd ip stack?

:P~

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