New releases (with security fixes): Tor 0.3.5.14, 0.4.4.8, and 0.4.5.7
We have a new stable release today. If you build Tor from source, you can download the source code for 0.4.5.7 on the download page. Packages should be available within the next several weeks, with a new Tor Browser coming next week.
Also today, Tor 0.3.5.14 (changelog) and Tor 0.4.4.8 (changelog) have also been released; you can find them (and source for older Tor releases) at https://utuhewzcso.oedi.net.
These releases fix a pair of denial-of-service issues, described below. One of these issues is authority-only. The other issue affects all Tor instances, and is most damaging on directory authorities and relays. We recommend that everybody should upgrade to one of these versions once packages are available.
Tor 0.4.5.7 fixes two important denial-of-service bugs in earlier versions of Tor.
One of these vulnerabilities (TROVE-2021-001) would allow an attacker who can send directory data to a Tor instance to force that Tor instance to consume huge amounts of CPU. This is easiest to exploit against authorities, since anybody can upload to them, but directory caches could also exploit this vulnerability against relays or clients when they download. The other vulnerability (TROVE-2021-002) only affects directory authorities, and would allow an attacker to remotely crash the authority with an assertion failure. Patches have already been provided to the authority operators, to help ensure network stability.
We recommend that everybody upgrade to one of the releases that fixes these issues (0.3.5.14, 0.4.4.8, or 0.4.5.7) as they become available to you.
This release also updates our GeoIP data source, and fixes a few smaller bugs in earlier releases.
Changes in version 0.4.5.7 - 2021-03-16
- Major bugfixes (security, denial of service):
- Disable the dump_desc() function that we used to dump unparseable information to disk. It was called incorrectly in several places, in a way that could lead to excessive CPU usage. Fixes bug 40286; bugfix on 0.2.2.1-alpha. This bug is also tracked as TROVE-2021- 001 and CVE-2021-28089.
- Fix a bug in appending detached signatures to a pending consensus document that could be used to crash a directory authority. Fixes bug 40316; bugfix on 0.2.2.6-alpha. Tracked as TROVE-2021-002 and CVE-2021-28090.
- Minor features (geoip data):
- We have switched geoip data sources. Previously we shipped IP-to- country mappings from Maxmind's GeoLite2, but in 2019 they changed their licensing terms, so we were unable to update them after that point. We now ship geoip files based on the IPFire Location Database instead. (See https://location.ipfire.org/ for more information). This release updates our geoip files to match the IPFire Location Database as retrieved on 2021/03/12. Closes ticket 40224.
- Minor bugfixes (directory authority):
- Now that exit relays don't allow exit connections to directory authority DirPorts (to prevent network reentry), disable authorities' reachability self test on the DirPort. Fixes bug 40287; bugfix on 0.4.5.5-rc.
- Minor bugfixes (documentation):
- Fix a formatting error in the documentation for VirtualAddrNetworkIPv6. Fixes bug 40256; bugfix on 0.2.9.4-alpha.
- Minor bugfixes (Linux, relay):
- Fix a bug in determining total available system memory that would have been triggered if the format of Linux's /proc/meminfo file had ever changed to include "MemTotal:" in the middle of a line. Fixes bug 40315; bugfix on 0.2.5.4-alpha.
- Minor bugfixes (metrics port):
- Fix a BUG() warning on the MetricsPort for an internal missing handler. Fixes bug 40295; bugfix on 0.4.5.1-alpha.
- Minor bugfixes (onion service):
- Remove a harmless BUG() warning when reloading tor configured with onion services. Fixes bug 40334; bugfix on 0.4.5.1-alpha.
- Minor bugfixes (portability):
- Fix a non-portable usage of "==" with "test" in the configure script. Fixes bug 40298; bugfix on 0.4.5.1-alpha.
- Minor bugfixes (relay):
- Remove a spammy log notice falsely claiming that the IPv4/v6 address was missing. Fixes bug 40300; bugfix on 0.4.5.1-alpha.
- Do not query the address cache early in the boot process when deciding if a relay needs to fetch early directory information from an authority. This bug resulted in a relay falsely believing it didn't have an address and thus triggering an authority fetch at each boot. Related to our fix for 40300.
- Removed features (mallinfo deprecated):
- Remove mallinfo() usage entirely. Libc 2.33+ now deprecates it. Closes ticket 40309.
Comments
Please note that the comment area below has been archived.
Both major fixes are for…
Both major fixes are for directory authorities. Those are run by people who communicate closely with Tor Project and so can deeply analyze bugs together. Are metrics enough to find and analyze these sorts of deep bugs in the procedures of relays? Are we missing more bugs in relay operations than are found for directory authorities?
Critical problem since 0.4…
Critical problem since 0.4.5.6. Torbrowser can not create circuit through transparent proxy https://learn.adafruit.com/onion-pi/overview
https://github.com/grugq/PORTALofPi
https://github.com/grugq/portal
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] Opening Socks listener on 127.0.0.1:9150
[NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
[NOTICE] Bootstrapped 5% (conn): Connecting to a relay
[NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
[WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (TLS_ERROR; TLS_ERROR; count 10; recommendation warn; host XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX at xxx.xxx.xxx.xxx:xxx)
[WARN] 10 connections have failed:
[WARN] 10 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
[NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] Delaying directory fetches: DisableNetwork is set.
Few exit circuits created by tor daemon on PORTALofPi allow torbrowser work. Majority give SSLv3/TLS write client hello in HANDSHAKE error when torbrowser on desktop computer attempts to connect through transparent proxy Pi. Someone show how create bug report?
> exit circuits created by…
> exit circuits created by tor daemon
Do you mean "exit circuit" in contrast to an "onion service circuit"?
> torbrowser on desktop computer attempts to connect through transparent proxy Pi.
Maybe don't do that.
https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO#tor-o…
https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorPlusVPN#you-to…
In 0.3.5.13, 0.4.3.8, and 0.4.4.7, backported from 0.4.5.5-rc: "Re-entry into the network is now denied at the Exit level to all relays' ORPorts and authorities' ORPorts and DirPorts. This change should help mitgate a set of denial-of-service attacks. Closes ticket 2667."
Another thing is that your guard could have become inaccessible at no fault of your LAN. Search if your guard is offline by pasting its IP or fingerprint into Relay Search on the Metrics portal. If your guard is offline, you could wait for it to come back online, or you could change your guard. It is usually safer to wait. Your guard is saved in your "state" file in the same directory as your torrc file. If you're running the daemon by itself as implied by the OS links you pasted, search for the default locations of the torrc file in the tor manual. However, you said you were doing both: running Tor Browser which is bundled with a tor daemon on your local device, as well as running a tor daemon on a Pi.