Is Tor vulnerable to takeover or not?

[nsane.forums]

A French researcher claims that he and two colleagues have found a serious hole in the security of Tor, the encrypted “darknet” widely used to protect privacy on the Web and to shield dissidents and others from monitoring and eavesdropping. The assertion has created a mix of concern and outrage in the Internet privacy community, particularly over the researcher's lack of disclosure to the foundation that manages Tor’s code base.

Eric Filiol, head of the Operational Cryptography and Computer Virology lab at the École Supérieure d’Informatique, Electronique, Automatique (ESIEA) in Paris, will discuss the exploit in a presentation at the Hackers to Hackers Conference in Sao Paulo, Brazil on October 29. Called “How to take over the Tor network operationally,” the talk will describe how “it is possible to take over a significant part of the Tor network by combining the concept of dynamic cryptographic backdoors with some protocol weaknesses found in the Tor network.”

The attacks developed at ESIEA were tested on 50-node simulated Tor network—and on part of the Tor network itself. "Those attacks rely mainly on the fact that the cryptography used in Tor is weakly implemented," Filiol wrote.

Filliol is currently traveling to Brazil to deliver his presentation and was not available to comment to Ars Technica.

Disclosure ethics

Tor, originally known as "the onion router," uses a set of protocols and an army of “relay” systems scattered across the Internet to pass traffic from a user’s computer in encrypted form to a distant gateway system. There it emerges back onto the "regular" Internet, hiding the original user's IP address and other data. The Tor network also supports "hidden services," which can be used to create hidden websites or other Internet services that exist only within the Tor network, obscuring them from the wider Internet. Some governments don't like either part of this functionality, and thus take pains to block access to Tor.

Filiol told the French technology site ITespresso that he and his team had been able to create a complete topographical map of the Tor network, discovering “hidden nodes” in the network—the unlisted Tor bridge relays that provide access to users whose ISPs block access to known Tor relays. He also claimed that the researchers were able to defeat the encryption of the Tor network, creating a virus that could essentially take control over a section of it. Half of the systems on the Tor network run Windows, Filiol said, and about a third of those systems are potentially vulnerable.

Filiol isn’t revealing any of his team’s attack methods yet, saying he’s holding details back until after he presents them at Hackers to Hackers and the PacSec conference in November.

“I have decided not to disclose anything for fairness purposes [with regard to] H2HC & PacSec organizers,” he wrote on Twitter yesterday. “Otherwise why attend hacking conferences?”

In a blog post on Monday, the Tor Foundation disputed some of Filiol’s assertions about the makeup of the network. The statement on the “rumors of Tor’s compromise” argued that Filiol’s data was significantly flawed. Filiol allegedly over-counted the number of Tor relays—the systems that provide the anonymizing routing for users of the Tor service—and under-counted the number of hidden Tor bridges. The Tor Project team also remarked that Filiol and his team had not shared any information with the Tor Foundation about the nature of the attack they had developed. “They have not talked to us, nor shared any data with us—despite some mail exchanges where we reminded him about the phrase ‘responsible disclosure.'”

In an earlier e-mail sent to the tor-talk email list after the ITespresso story, Tor Foundation executive director Andrew Lewman complained that Filiol “has refused to talk to us in any responsible manner. This article is full of hyperbole, but short on facts.” Lewman speculated that the exploit Filiol had used should more likely be characterized as a Windows attack, rather than one on Tor itself.

By way of reply to Lewman’s complaint, Filiol wrote on Twitter, “[The] Tor foundation asked (not to say require) technical details in advance without proposing to work under NDA. So guess what happened?” He said in another post that he was “fed up” with the Tor Foundation’s complaints and speculations, and urged people to attend his presentations to make up their own minds about the validity of the attack.

Filiol’s work has drawn criticism before. In 2003, he published a paper claiming that the AES encryption algorithm could be broken through a simple ciphertext block attack, but he later modified his claims. A team of researchers trying to replicate his results found that even his modified claims could not be reproduced. One Luxembourg-based security expert complained on Twitter, “Every few years, Eric Filiol claims an amazing infosec discovery which turns out to be nonsense.”

View: Original Article

[hullboy]

Tor 0.2.2.34 is out

Changes in version 0.2.2.34 - 2011-10-26

  Tor 0.2.2.34 fixes a critical anonymity vulnerability where an attacker
  can deanonymize Tor users. Everybody should upgrade.
  The attack relies on four components: 1) Clients reuse their TLS cert
  when talking to different relays, so relays can recognize a user by
  the identity key in her cert. 2) An attacker who knows the client's
  identity key can probe each guard relay to see if that identity key
  is connected to that guard relay right now. 3) A variety of active
  attacks in the literature (starting from "Low-Cost Traffic Analysis
  of Tor" by Murdoch and Danezis in 2005) allow a malicious website to
  discover the guard relays that a Tor user visiting the website is using.
  4) Clients typically pick three guards at random, so the set of guards
  for a given user could well be a unique fingerprint for her. This
  release fixes components #1 and #2, which is enough to block the attack;
  the other two remain as open research problems. Special thanks to
  "frosty_un" for reporting the issue to us!
  Clients should upgrade so they are no longer recognizable by the TLS
  certs they present. Relays should upgrade so they no longer allow a
  remote attacker to probe them to test whether unpatched clients are
  currently connected to them.
  This release also fixes several vulnerabilities that allow an attacker
  to enumerate bridge relays. Some bridge enumeration attacks still
  remain; see for example proposal 188.
  o Privacy/anonymity fixes (clients):
	- Clients and bridges no longer send TLS certificate chains on
	  outgoing OR connections. Previously, each client or bridge
	  would use the same cert chain for all outgoing OR connections
	  for up to 24 hours, which allowed any relay that the client or
	  bridge contacted to determine which entry guards it is using.
	  Fixes CVE-2011-2768. Bugfix on 0.0.9pre5; found by "frosty_un".
	- If a relay receives a CREATE_FAST cell on a TLS connection, it
	  no longer considers that connection as suitable for satisfying a
	  circuit EXTEND request. Now relays can protect clients from the
	  CVE-2011-2768 issue even if the clients haven't upgraded yet.
	- Directory authorities no longer assign the Guard flag to relays
	  that haven't upgraded to the above "refuse EXTEND requests
	  to client connections" fix. Now directory authorities can
	  protect clients from the CVE-2011-2768 issue even if neither
	  the clients nor the relays have upgraded yet. There's a new
	  "GiveGuardFlagTo_CVE_2011_2768_VulnerableRelays" config option
	  to let us transition smoothly, else tomorrow there would be no
	  guard relays.
  o Privacy/anonymity fixes (bridge enumeration):
	- Bridge relays now do their directory fetches inside Tor TLS
	  connections, like all the other clients do, rather than connecting
	  directly to the DirPort like public relays do. Removes another
	  avenue for enumerating bridges. Fixes bug 4115; bugfix on 0.2.0.35.
	- Bridges relays now build circuits for themselves in a more similar
	  way to how clients build them. Removes another avenue for
	  enumerating bridges. Fixes bug 4124; bugfix on 0.2.0.3-alpha,
	  when bridges were introduced.
	- Bridges now refuse CREATE or CREATE_FAST cells on OR connections
	  that they initiated. Relays could distinguish incoming bridge
	  connections from client connections, creating another avenue for
	  enumerating bridges. Fixes CVE-2011-2769. Bugfix on 0.2.0.3-alpha.
	  Found by "frosty_un".
  o Major bugfixes:
	- Fix a crash bug when changing node restrictions while a DNS lookup
	  is in-progress. Fixes bug 4259; bugfix on 0.2.2.25-alpha. Bugfix
	  by "Tey'".
	- Don't launch a useless circuit after failing to use one of a
	  hidden service's introduction points. Previously, we would
	  launch a new introduction circuit, but not set the hidden service
	  which that circuit was intended to connect to, so it would never
	  actually be used. A different piece of code would then create a
	  new introduction circuit correctly. Bug reported by katmagic and
	  found by Sebastian Hahn. Bugfix on 0.2.1.13-alpha; fixes bug 4212.
  o Minor bugfixes:
	- Change an integer overflow check in the OpenBSD_Malloc code so
	  that GCC is less likely to eliminate it as impossible. Patch
	  from Mansour Moufid. Fixes bug 4059.
	- When a hidden service turns an extra service-side introduction
	  circuit into a general-purpose circuit, free the rend_data and
	  intro_key fields first, so we won't leak memory if the circuit
	  is cannibalized for use as another service-side introduction
	  circuit. Bugfix on 0.2.1.7-alpha; fixes bug 4251.
	- Bridges now skip DNS self-tests, to act a little more stealthily.
	  Fixes bug 4201; bugfix on 0.2.0.3-alpha, which first introduced
	  bridges. Patch by "warms0x".
	- Fix internal bug-checking logic that was supposed to catch
	  failures in digest generation so that it will fail more robustly
	  if we ask for a nonexistent algorithm. Found by Coverity Scan.
	  Bugfix on 0.2.2.1-alpha; fixes Coverity CID 479.
	- Report any failure in init_keys() calls launched because our
	  IP address has changed. Spotted by Coverity Scan. Bugfix on
	  0.1.1.4-alpha; fixes CID 484.
  o Minor bugfixes (log messages and documentation):
	- Remove a confusing dollar sign from the example fingerprint in the
	  man page, and also make the example fingerprint a valid one. Fixes
	  bug 4309; bugfix on 0.2.1.3-alpha.
	- The next version of Windows will be called Windows 8, and it has
	  a major version of 6, minor version of 2. Correctly identify that
	  version instead of calling it "Very recent version". Resolves
	  ticket 4153; reported by funkstar.
	- Downgrade log messages about circuit timeout calibration from
	  "notice" to "info": they don't require or suggest any human
	  intervention. Patch from Tom Lowenthal. Fixes bug 4063;
	  bugfix on 0.2.2.14-alpha.
  o Minor features:
	- Turn on directory request statistics by default and include them in
	  extra-info descriptors. Don't break if we have no GeoIP database.
	  Backported from 0.2.3.1-alpha; implements ticket 3951.
	- Update to the October 4 2011 Maxmind GeoLite Country database.