On Thu, Aug 02, 2007 at 06:19:18PM -0400, Roger Dingledine wrote: > Tor 0.1.2.16 fixes a critical security vulnerability that allows a > remote attacker in certain situations to rewrite the user's torrc > configuration file. This can completely compromise anonymity of users > in most configurations, including those running the Vidalia bundles, > TorK, etc. Or worse. Here are the further details that we promised: In a nutshell, a malicious website or Tor exit node can give the Tor user a page that includes a POST element directed to Tor's control port (localhost:9051). Tor binds its control port only to localhost to avoid letting untrusted people send it commands, but the attacker skips past this protection by making the browser do the connection. And the user doesn't even have to click on anything if she's got javascript enabled. This particular attack worked because Tor's control protocol gave an error message on unrecognized commands but didn't hang up. So all the http headers from the POST were unrecognized commands, and eventually we got to the payload -- which contains recognized commands -- and it went bad from there. Jochen Topf wrote a fine paper describing this attack in 2001: http://www.remote.org/jochen/sec/hfpa/index.html Thanks to Kyle Williams and Martin Peck who independently rediscovered the attack in the context of Tor. The 0.1.2.16 and 0.2.0.4-alpha versions of Tor patched this particular problem by hanging up if the first command wasn't a successful 'authenticate' command. The recently released 0.1.2.17 and 0.2.0.6-alpha versions of Tor now enable application-level authentication by default in the Windows and OS X bundles, which should stop a broad class of related attacks. Everyone should upgrade. Yay full disclosure, --Roger
Attachment:
signature.asc
Description: Digital signature