Several issues have been discovered in Tor, a connection-based low-latency anonymous communication system, resulting in information leaks. Relay-early cells could be used by colluding relays on the network to tag user circuits and so deploy traffic confirmation attacks [CVE-2014-5117]. The updated version emits a warning and drops the circuit upon receiving inbound relay-early cells, preventing this specific kind of attack. Please consult the following advisory for more details about this issue: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack A bug in the bounds-checking in the 32-bit curve25519-donna implementation could cause incorrect results on 32-bit implementations when certain malformed inputs were used along with a small class of private ntor keys. This flaw does not currently appear to allow an attacker to learn private keys or impersonate a Tor server, but it could provide a means to distinguish 32-bit Tor implementations from 64-bit Tor implementations. The following additional security-related improvements have been implemented: As a client, the new version will effectively stop using CREATE_FAST cells. While this adds computational load on the network, this approach can improve security on connections where Tor's circuit handshake is stronger than the available TLS connection security levels. Prepare clients to use fewer entry guards by honoring the consensus parameters. The following article provides some background: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters For the stable distribution (wheezy), these problems have been fixed in version 0.2.4.23-1~deb7u1. For the testing distribution (jessie) and the unstable distribution (sid), these problems have been fixed in version 0.2.4.23-1. For the experimental distribution, these problems have been fixed in version 0.2.5.6-alpha-1. We recommend that you upgrade your tor packages.
Several issues have been discovered in Tor, a connection-based low-latency anonymous communication system, resulting in information leaks.
Relay-early cells could be used by colluding relays on the network to tag user circuits and so deploy traffic confirmation attacks [CVE-2014-5117]. The updated version emits a warning and drops the circuit upon receiving inbound relay-early cells, preventing this specific kind of attack. Please consult the following advisory for more details about this issue:
https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
A bug in the bounds-checking in the 32-bit curve25519-donna implementation could cause incorrect results on 32-bit implementations when certain malformed inputs were used along with a small class of private ntor keys. This flaw does not currently appear to allow an attacker to learn private keys or impersonate a Tor server, but it could provide a means to distinguish 32-bit Tor implementations from 64-bit Tor implementations.
The following additional security-related improvements have been implemented:
As a client, the new version will effectively stop using CREATE_FAST cells. While this adds computational load on the network, this approach can improve security on connections where Tor's circuit handshake is stronger than the available TLS connection security levels.
Prepare clients to use fewer entry guards by honoring the consensus parameters. The following article provides some background:
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
For the stable distribution (wheezy), these problems have been fixed in version 0.2.4.23-1~deb7u1.
For the testing distribution (jessie) and the unstable distribution (sid), these problems have been fixed in version 0.2.4.23-1.
For the experimental distribution, these problems have been fixed in version 0.2.5.6-alpha-1.
We recommend that you upgrade your tor packages.
Vulmon