New Stable Releases: Tor 0.3.5.16, 0.4.5.10 and 0.4.6.7

by dgoulet | August 16, 2021

Greetings!

We have a new stable release today. If you build Tor from source, you can download the source code for the latest stable release on the download page. Packages should be available within the next several weeks, with a new Tor Browser later this week.

The ChangeLog for 0.4.6.7 follows below. For the changelogs for other releases, see the announcement email. These releases backport stability fixes from later Tor releases, and a security issue classified as HIGH per our policy.

Tor 0.4.6.7 fixes several bugs from earlier versions of Tor, including one that could lead to a denial-of-service attack. Everyone running an earlier version, whether as a client, a relay, or an onion service, should upgrade to Tor 0.3.5.16, 0.4.5.10, or 0.4.6.7.

Changes in version 0.4.6.7 - 2021-08-16

  • Major bugfixes (cryptography, security):
    • Resolve an assertion failure caused by a behavior mismatch between our batch-signature verification code and our single-signature verification code. This assertion failure could be triggered remotely, leading to a denial of service attack. We fix this issue by disabling batch verification. Fixes bug 40078; bugfix on 0.2.6.1-alpha. This issue is also tracked as TROVE-2021-007 and CVE-2021-38385. Found by Henry de Valence.
  • Minor feature (fallbackdir):
    • Regenerate fallback directories list. Close ticket 40447. 
  • Minor features (geoip data):
    • Update the geoip files to match the IPFire Location Database, as retrieved on 2021/08/12.
  • Minor bugfix (crypto):
    • Disable the unused batch verification feature of ed25519-donna. Fixes bug 40078; bugfix on 0.2.6.1-alpha. Found by Henry de Valence.
  • Minor bugfixes (onion service):
    • Send back the extended SOCKS error 0xF6 (Onion Service Invalid Address) for a v2 onion address. Fixes bug 40421; bugfix on 0.4.6.2-alpha.
  • Minor bugfixes (relay):
    • Reduce the compression level for data streaming from HIGH to LOW in order to reduce CPU load on the directory relays. Fixes bug 40301; bugfix on 0.3.5.1-alpha.
  • Minor bugfixes (timekeeping):
    • Calculate the time of day correctly on systems where the time_t type includes leap seconds. (This is not the case on most operating systems, but on those where it occurs, our tor_timegm function did not correctly invert the system's gmtime function, which could result in assertion failures when calculating voting schedules.) Fixes bug 40383; bugfix on 0.2.0.3-alpha.

Comments

Please note that the comment area below has been archived.

NoName (not verified) said:

August 17, 2021

Permalink

I hope this time around the deb.torproject.org actually upgrades to 0.4.6.7 for all (the last few releases of 0.4.6.* have not been updated other than as experimental despite them being stable!).

As was noted on gitlab.torproject.org/tpo/tpa/team/-/issues/40221#note_2745110 the newer versions were held off due to Debian 11 Bullseye freeze, but now that it has been released that should not be any blocking issue for upgrading to 0.4.6.

Anonymous (not verified) said:

September 18, 2021

Permalink

Zero ed_pubkey lets an attacker force the relay to hold open a new TLS connection for _some_ extend request.

circuit_extend_add_ed25519_helper:

/* Fill in ed_pubkey if it was not provided and we can infer it from
* our networkstatus */
if (ed25519_public_key_is_zero(&ec->ed_pubkey)) {
const node_t *node = node_get_by_id((const char*)ec->node_id);
const ed25519_public_key_t *node_ed_id = NULL;
if (node &&
node_supports_ed25519_link_authentication(node, 1) &&
(node_ed_id = node_get_ed25519_id(node))) {
ed25519_pubkey_copy(&ec->ed_pubkey, node_ed_id);
}
}

ed_pubkey is optional if no node information.

channel_get_for_extend:

/* The Ed25519 key has to match too */
if (!channel_remote_identity_matches(chan, rsa_id_digest, ed_id)) {
continue;
}

ed_pubkey is not optional for channel reuse.