Tor 0.3.1.4-alpha is released (with security update for clients)

Hello again! This post announces the fourth alpha in the 0.3.1.x series, which we just released today. There's a stable release too; I'll mention that in the next post.

Tor 0.3.1.4-alpha fixes a path selection bug that would allow a client to use a guard that was in the same network family as a chosen exit relay. This is a security regression; all clients running earlier versions of 0.3.0.x or 0.3.1.x should upgrade to 0.3.0.9 or 0.3.1.4-alpha.

This release also fixes several other bugs introduced in 0.3.0.x and 0.3.1.x, including others that can affect bandwidth usage and correctness.

Since this is an alpha release, you can expect more bugs than usual. If you'd rather have a more stable experience, stick to the stable releases.

If you build Tor from source, you can find Tor 0.3.1.4-alpha at the usual place (at the Download page on our website). Otherwise, you'll probably want to wait until packages are available. There should be a new Tor Browser release early next week.

Changes in version 0.3.1.4-alpha - 2017-06-29

  • New dependencies:
    • To build with zstd and lzma support, Tor now requires the pkg-config tool at build time. (This requirement was new in 0.3.1.1-alpha, but was not noted at the time. Noting it here to close ticket 22623.)
  • Major bugfixes (path selection, security):
    • When choosing which guard to use for a circuit, avoid the exit's family along with the exit itself. Previously, the new guard selection logic avoided the exit, but did not consider its family. Fixes bug 22753; bugfix on 0.3.0.1-alpha. Tracked as TROVE-2016- 006 and CVE-2017-0377.

 

  • Major bugfixes (compression, zstd):
    • Correctly detect a full buffer when decompressing a large zstd- compressed input. Previously, we would sometimes treat a full buffer as an error. Fixes bug 22628; bugfix on 0.3.1.1-alpha.
  • Major bugfixes (directory protocol):
    • Ensure that we send "304 Not modified" as HTTP status code when a client is attempting to fetch a consensus or consensus diff, and the best one we can send them is one they already have. Fixes bug 22702; bugfix on 0.3.1.1-alpha.
  • Major bugfixes (entry guards):
    • When starting with an old consensus, do not add new entry guards unless the consensus is "reasonably live" (under 1 day old). Fixes one root cause of bug 22400; bugfix on 0.3.0.1-alpha.
  • Minor features (bug mitigation, diagnostics, logging):
    • Avoid an assertion failure, and log a better error message, when unable to remove a file from the consensus cache on Windows. Attempts to mitigate and diagnose bug 22752.
  • Minor features (geoip):
    • Update geoip and geoip6 to the June 8 2017 Maxmind GeoLite2 Country database.
  • Minor bugfixes (compression):
    • When compressing or decompressing a buffer, check for a failure to create a compression object. Fixes bug 22626; bugfix on 0.3.1.1-alpha.
    • When decompressing a buffer, check for extra data after the end of the compressed data. Fixes bug 22629; bugfix on 0.3.1.1-alpha.
    • When decompressing an object received over an anonymous directory connection, if we have already decompressed it using an acceptable compression method, do not reject it for looking like an unacceptable compression method. Fixes part of bug 22670; bugfix on 0.3.1.1-alpha.
    • When serving directory votes compressed with zlib, do not claim to have compressed them with zstd. Fixes bug 22669; bugfix on 0.3.1.1-alpha.
    • When spooling compressed data to an output buffer, don't try to spool more data when there is no more data to spool and we are not trying to flush the input. Previously, we would sometimes launch compression requests with nothing to do, which interferes with our 22672 checks. Fixes bug 22719; bugfix on 0.2.0.16-alpha.
  • Minor bugfixes (defensive programming):
    • Detect and break out of infinite loops in our compression code. We don't think that any such loops exist now, but it's best to be safe. Closes ticket 22672.
    • Fix a memset() off the end of an array when packing cells. This bug should be harmless in practice, since the corrupted bytes are still in the same structure, and are always padding bytes, ignored, or immediately overwritten, depending on compiler behavior. Nevertheless, because the memset()'s purpose is to make sure that any other cell-handling bugs can't expose bytes to the network, we need to fix it. Fixes bug 22737; bugfix on 0.2.4.11-alpha. Fixes CID 1401591.
  • Minor bugfixes (linux seccomp2 sandbox):
    • Permit the fchmod system call, to avoid crashing on startup when starting with the seccomp2 sandbox and an unexpected set of permissions on the data directory or its contents. Fixes bug 22516; bugfix on 0.2.5.4-alpha.
    • Fix a crash in the LZMA module, when the sandbox was enabled, and liblzma would allocate more than 16 MB of memory. We solve this by bumping the mprotect() limit in the sandbox module from 16 MB to 20 MB. Fixes bug 22751; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (logging):
    • When decompressing, do not warn if we fail to decompress using a compression method that we merely guessed. Fixes part of bug 22670; bugfix on 0.1.1.14-alpha.
    • When decompressing, treat mismatch between content-encoding and actual compression type as a protocol warning. Fixes part of bug 22670; bugfix on 0.1.1.9-alpha.
    • Downgrade "assigned_to_cpuworker failed" message to info-level severity. In every case that can reach it, either a better warning has already been logged, or no warning is warranted. Fixes bug 22356; bugfix on 0.2.6.3-alpha.
    • Demote a warn that was caused by libevent delays to info if netflow padding is less than 4.5 seconds late, or to notice if it is more (4.5 seconds is the amount of time that a netflow record might be emitted after, if we chose the maximum timeout). Fixes bug 22212; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (process behavior):
    • When exiting because of an error, always exit with a nonzero exit status. Previously, we would fail to report an error in our exit status in cases related to __OwningControllerProcess failure, lockfile contention, and Ed25519 key initialization. Fixes bug 22720; bugfix on versions 0.2.1.6-alpha, 0.2.2.28-beta, and 0.2.7.2-alpha respectively. Reported by "f55jwk4f"; patch from "huyvq".
  • Documentation:
    • Add a manpage description for the key-pinning-journal file. Closes ticket 22347.
    • Correctly note that bandwidth accounting values are stored in the state file, and the bw_accounting file is now obsolete. Closes ticket 16082.
    • Document more of the files in the Tor data directory, including cached-extrainfo, secret_onion_key{,_ntor}.old, hidserv-stats, approved-routers, sr-random, and diff-cache. Found while fixing ticket 22347.
Anonymous

July 08, 2017

Permalink

[07-08 17:59:58] Torbutton INFO: controlPort >> 650 STREAM 2187 NEW 0 1.1.1.1.$AAA...EEE.exit:53 PURPOSE=DIR_FETCH
[07-08 17:59:58] Torbutton INFO: controlPort >> 650 STREAM 2189 NEW 0 1.1.1.1.$AAA...EEE.exit:53 PURPOSE=DIR_FETCH
[07-08 17:59:58] Torbutton INFO: controlPort >> 650 STREAM 2191 NEW 0 1.1.1.1.$AAA...EEE.exit:53 PURPOSE=DIR_FETCH
Why the same node? Why 3 times in a row? Why STREAM numbers are odd only?

Not sure, to be honest. Does that issue go away with older tor versions? You could test that with extracting the expert bundle (you'll find the respective tor-win32*zip files in the Tor Browser bundles directories at https://archive.torproject.org/tor-package-archive/torbrowser/) and copyinf the tor.exe file over the one in the Tor Browser you are using? Maybe we can first narrow down the problem to be either in the tor or the Tor Browser area that way.

Is this really an issue? Isn't it a Tor issue?
Tor stable 0.3.0.9: three, to the same, even, i.e. STREAM numbers could be odd or even.
The whole algorithm looks like this: STREAM 169 NODE. When DONE, STREAM 172,174,176 NODE. 2 streams (170,171) also disappeared.

Anonymous

July 14, 2017

Permalink

tor_bug_occurred_(): Bug: consdiffmgr.c:1289: store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at consdiffmgr.c:1289. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)

Anonymous

July 14, 2017

Permalink

Unable to unlink ".\\Data\\Tor\\LocalState\\diff-cache/1001" while removing file: Permission denied
tor_bug_occurred_(): Bug: consdiffmgr.c:1289: store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at consdiffmgr.c:1289. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)
tor_bug_occurred_(): Bug: consdiffmgr.c:328: cdm_diff_ht_purge: Non-fatal assertion !((*diff)->entry == NULL) failed. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Bug: Non-fatal assertion !((*diff)->entry == NULL) failed in cdm_diff_ht_purge at consdiffmgr.c:328. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)
eventdns: All nameservers have failed

Anonymous

July 20, 2017

Permalink

Plse disregard last request for help RE Bad Gateway 502 Error. I added an "Inbound Rule" in Windows Firewall for the TOR executable for firefox.exe, defaulted everything, and that seems to have done the trick for the time being. Anyone using Windows Firewall might want to check this out.

Also forgot to mention that I'm using Windows 7 "Home Premium." Have no idea how this would play out in Windows 8 or 10, and don't want to know.

Response is on the slow side, but I kind of expected that for anonymous browsing. I'll work through the other blog posts and community support to try to resolve that.

Join the discussion...

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

7 + 10 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.