Tor before 0.4.9.11 is prone to a use-after-free (and potential double free) of a conflux object when a recovery leg revives a conflux set whose last linked leg has already been closed. A malicious exit node could use this to crash a client. This is TROVE-2026-026.

Jann Horn (CC'd) identified a problem in current versions of libseccomp where the library did not correctly generate 64-bit syscall argument comparisons using the arithmetic operators (LT, GT, LE, GE). Jann has done a search using codesearch.debian.net and it would appear that only systemd and Tor are using libseccomp in such a way as to trigger the bad code. In the case of systemd this appears to affect the socket address family and scheduling class filters. In the case of Tor it appears that the bad filters could impact the memory addresses passed to mprotect(2).

The libseccomp v2.4.0 release fixes this problem, and should be a direct drop-in replacement for previous v2.x releases. Due the complexity, and associated risk, of backporting the fix to the v2.3.x release stream, I've made the difficult decision not to backport the fix. Further, I'm not aware of any workarounds for this issue. Adminstrators and distros are strongly encouraged to upgrade to libseccomp v2.4.0 as soon as possible.

The related GitHub issue, complete with a brief discussion of the problem and a list of the assocated patches can be found at the link below:

https://github.com/seccomp/libseccomp/issues/139

The libseccomp v2.4.0 release can be found at the link below:

https://github.com/seccomp/libseccomp/releases/tag/v2.4.0

-- paul moore www.paul-moore.com

The networkstatusparsevotefromstring function in routerparse.c in Tor before 0.2.2.38 does not properly handle an invalid flavor name, which allows remote attackers to cause a denial of service (out-of-bounds read and daemon crash) via a crafted (1) vote document or (2) consensus document.

routerlist.c in Tor before 0.2.2.38 uses a different amount of time for relay-list iteration depending on which relay is chosen, which might allow remote attackers to obtain sensitive information about relay selection via a timing side-channel attack.

A read from already freed memory and double free flaws were found in the way Tor, a connection-based low-latency anonymous communication system, performed processing of certain failing DNS requests. A remote attacker could issue a specially-crafted DNS request that, when processed would lead to tor executable crash.

Upstream ticket: [1] https://trac.torproject.org/projects/tor/ticket/6480

Relevant patch: [2] https://gitweb.torproject.org/tor.git/commitdiff/62637fa22405278758febb1743da9af562524d4c

References: [3] https://lists.torproject.org/pipermail/tor-announce/2012-August/000086.html [4] https://bugzilla.novell.com/showbug.cgi?id=776642

Tor before 0.2.2.24-alpha continues to use a reachable bridge that was previously configured but is not currently configured, which might allow remote attackers to obtain sensitive information about clients in opportunistic circumstances by monitoring network traffic to the bridge port.

Tor before 0.2.2.34, when configured as a bridge, uses direct DirPort access instead of a Tor TLS connection for a directory fetch, which makes it easier for remote attackers to enumerate bridges by observing DirPort connections.

Tor before 0.2.2.34, when configured as a bridge, sets up circuits through a process different from the process used by a client, which makes it easier for remote attackers to enumerate bridges by observing circuit building.

Tor before 0.2.2.25-alpha, when configured as a relay without the Nickname configuration option, uses the local hostname as the Nickname value, which allows remote attackers to obtain potentially sensitive information by reading this value.

Tor before 0.2.2.34, when configured as a client or bridge, sends a TLS certificate chain as part of an outgoing OR connection, which allows remote relays to bypass intended anonymity properties by reading this chain and then determining the set of entry guards that the client or bridge had selected.

Tor before 0.2.2.34, when configured as a bridge, accepts the CREATE and CREATEFAST values in the Command field of a cell within an OR connection that it initiated, which allows remote relays to enumerate bridges by using these values.

Multiple heap-based buffer overflows in Tor before 0.2.2.35 allow remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by (1) establishing a SOCKS connection to SocksPort or (2) leveraging a SOCKS proxy configuration.

A vulnerability in Tor was reported [1] that could allow a malicious remote attacker to cause a denial of service. This vulnerability is due to a boundary error within the policysummarize() function in src/or/policies.c which can be exploited to crash a Tor directory authority.

Upstream announced the release of 0.2.1.30 [2] that is noted to correct this flaw.

[1] http://secunia.com/advisories/43548/ [2] https://lists.torproject.org/pipermail/tor-announce/2011-February/000000.html

Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not properly manage key data in memory, which might allow local users to obtain sensitive information by leveraging the ability to read memory that was previously used by a different process.

Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not properly check the amount of compression in zlib-compressed data, which allows remote attackers to cause a denial of service via a large compression factor.

Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha makes calls to Libevent within Libevent log handlers, which might allow remote attackers to cause a denial of service (daemon crash) via vectors that trigger certain log messages.

Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha allows remote attackers to cause a denial of service (assertion failure and daemon exit) via blobs that trigger a certain file size, as demonstrated by the cached-descriptors.new file.

Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha might allow remote attackers to cause a denial of service (assertion failure and daemon exit) via vectors related to malformed router caches and improper handling of integer values.

The torrealloc function in Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not validate a certain size value during memory allocation, which might allow remote attackers to cause a denial of service (daemon crash) via unspecified vectors, related to "underflow errors."

Heap-based buffer overflow in Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unspecified vectors.

Heap-based buffer overflow in Tor before 0.2.1.28 and 0.2.2.x before 0.2.2.20-alpha allows remote attackers to cause a denial of service (daemon crash) or possibly execute arbitrary code via unspecified vectors.

Tor before 0.2.1.22, and 0.2.2.x before 0.2.2.7-alpha, when functioning as a bridge directory authority, allows remote attackers to obtain sensitive information about bridge identities and bridge descriptors via a dbg-stability.txt directory query.

Tor 0.2.2.x before 0.2.2.7-alpha, when functioning as a directory mirror, does not prevent logging of the client IP address upon detection of erroneous client behavior, which might make it easier for local users to discover the identities of clients in opportunistic circumstances by reading log files.

Tor before 0.2.1.22, and 0.2.2.x before 0.2.2.7-alpha, uses deprecated identity keys for certain directory authorities, which makes it easier for man-in-the-middle attackers to compromise the anonymity of traffic sources and destinations.

The connectionedgeprocessrelaycellnotopen function in src/or/relay.c in Tor 0.2.x before 0.2.0.35 and 0.1.x before 0.1.2.8-beta allows exit relays to have an unspecified impact by causing controllers to accept DNS responses that redirect to an internal IP address via unknown vectors. NOTE: some of these details are obtained from third party information.

Tor before 0.2.0.35 allows remote attackers to cause a denial of service (application crash) via a malformed router descriptor.

Unspecified vulnerability in Tor before 0.2.0.34 allows directory mirrors to cause a denial of service via unknown vectors.

Tor before 0.2.0.34 treats incomplete IPv4 addresses as valid, which has unknown impact and attack vectors related to "Spec conformance," as demonstrated using 192.168.0.

Unspecified vulnerability in Tor before 0.2.0.34 allows attackers to cause a denial of service (infinite loop) via "corrupt votes."

Unspecified vulnerability in Tor before 0.2.0.34 allows directory mirrors to cause a denial of service (exit node crash) via "malformed input."