Tor 0.3.0.9 is released (with security update for clients)

Source code for a new Tor release (0.3.0.9) is now available on the website.

Tor 0.3.0.9 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 when packages become available.  Packages should be available soon, along with a Tor Browser release early next week. 

One last reminder: Tor 0.2.4, 0.2.6, and 0.2.7 will no longer be supported after 1 August of this year.  Tor 0.2.8 will not be supported after 1 Jan of 2018.  Tor 0.2.5 will not be supported after 1 May of 2018.  If you need a release with long-term support, 0.2.9 is
what we recommend: we plan to support it until at least 1 Jan 2020.

This release also backports several other bugfixes from the 0.3.1.x series.

Changes in version 0.3.0.9 - 2017-06-29

  • Major bugfixes (path selection, security, backport from 0.3.1.4-alpha):    
    • 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 (entry guards, backport from 0.3.1.1-alpha):  
    • Don't block bootstrapping when a primary bridge is offline and we can't get its descriptor. Fixes bug 22325; fixes one case of bug 21969; bugfix on 0.3.0.3-alpha.  

 

  • Major bugfixes (entry guards, backport from 0.3.1.4-alpha):    
    • 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 (geoip):    
    • Update geoip and geoip6 to the June 8 2017 Maxmind GeoLite2 Country database.  
  • Minor bugfixes (voting consistency, backport from 0.3.1.1-alpha):    
    • Reject version numbers with non-numeric prefixes (such as +, -, or whitespace). Disallowing whitespace prevents differential version parsing between POSIX-based and Windows platforms. Fixes bug 21507 and part of 21508; bugfix on 0.0.8pre1.  
  • Minor bugfixes (linux seccomp2 sandbox, backport from 0.3.1.4-alpha):    
    • 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.  
  • Minor bugfixes (defensive programming, backport from 0.3.1.4-alpha):  
    • 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.  
Anonymous

June 29, 2017

Permalink

I would like some type of update process for which you may have the latest version of TBB, but a new version of Tor is released and you could choose to update Tor to the latest version within the current version of TBB, so you wouldn't have to wait X days or weeks in order to update to the latest version of TBB which has the latest version of Tor!

Just my 2 Lithuanian cents: If there's a version of Tor that has a serious bug for clients, they'll probably deploy a new release of the Tor Browser with the fix. But most of the time you don't need to always have a version more recent that the one that is bundled with your Tor Browser, so I don't think it would be worth the effort IMO.

A version release for one or more cosmetic or otherwise non-catastrophic bugs, is a violation of good SW process, as well as a waste of time and resources, including that of the user. Therefore zaps can be made available to the community for minor stuff, and releases reserved for level I and II faults, or when there have been enough zaps to warrant a major version push. It is, one may say, the unwritten rule of SW development, and just good sense.
luv

Anonymous

June 29, 2017

Permalink

Since version 7.0 entry node (IP/Server) & country never changes! This behavior is still present in 7.0.1. All entry nodes are now only from US, UK, France, Netherlands & occasionally Germany. Previously (in 6.x and older) entry nodes from vastly more countries were used.

Description below (tested with a clean TOR Browser install):

A-TOR Browser
1-Entry NODE (eN)
2-Middle NODE (mN)
3-Exit NODE (xN)
B-Internet

Old behavior (6.x or older) New behavior (7.x)
New eN from a different country Same eN IP & from the same country
----------------------------------- -----------------------------------
New Identity
Restart Tor Browser
Close Tor browser, then start another session

New Tor Circuit does change the mN & xN in 7.x, just as it did in older versions.

The only way to change the eN IP/Server and geographic location/country is to do the following:
1- exit Tor Browser
2- navigate to folder TorBrowser/Data/Tor
3- delete all the cached-* & control_auth_cookie
4- start Tor Browser

After this the eN IP/Server changes to one from only a handful of five different countries (as listed above). But then again the eN IP will always be stuck no matter what is done, that is until I follow the four steps above & delete all the cached files.

Please fix this. I liked the old behavior (also seems more secure to me), where clicking New Identity or restarting the Tor Browser also changed the eN.

> Since version 7.0 entry node (IP/Server) & country never changes!

Tor has used a Guard (fixed entry node) for years.

> Please fix this. I liked the old behavior (also seems more secure to me), where clicking New Identity or restarting the Tor Browser also changed the eN.

It's not more secure, and is quite a bit worse by a long margin. And the old behavior that you describe, would have been a massive anonymity bug if it existed in the first place.

> BUG or attack

Bug confirmed! Tor never generates a new circuit or chooses a entry node when New Identity (Ctrl+Shift+U) is selected or the browser itself is relaunched.

> 3- delete all the cached-* & control_auth_cookie

Thank you Sir! Now I can at least change the entry node server/IP, but still confined to the same geographic region; all of the entry nodes I've gotten so far is in the UK.

I have been stuck with the same entry node the past few weeks and was quite worried that I have somehow messed up the settings. Glad to know it wasn't just me.

> Tor has used a Guard (fixed entry node) for years.

I am not (and I don't think the OP did either) disputing the fact that Tor uses the same entry node throughout a session, only that entry node never changes if New Identity is selected or if the browser itself is relaunched.

> Please read the relevant FAQ:
> https://www.torproject.org/docs/faq.html.en#EntryGuards

What does any of this have to do with New Identity (Ctrl+Shift+U) not generating a new circuit? All it does is change the middle and exit nodes, the same as New Tor Circuit for this site (Ctrl+Shift+L)?

If this is by design then why not get rid of the New Identity (Ctrl+Shift+U) menu option?

> It's not more secure, and is quite a bit worse by a long margin.

So changing the entry node every time Tor Browser starts or a session is started by clicking New Identity (Ctrl+Shift+U) is less secure?

Let's say 1.1.1.1 located in the UK, is my entry node. Now please explain how using this same server/IP as the entry node for a year or more is secure (as the entry node never changes)? Anyone able to trace you to this entry node (very easily done) will be able to collect a year worth of data passing through.

So now, how do I report this to a dev?

> If this is by design then why not get rid of the New Identity (Ctrl+Shift+U) menu option?

The New Identity button also discards the application-level browser stuff like cookies. It is essentially like restarting Tor Browser -- it flushes the browser state.

> Now please explain how using this same server/IP as the entry node for a year or more is secure

The very short version is at the FAQ entry people pointed you to:
https://www.torproject.org/docs/faq#EntryGuards

Here is the much longer version:
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guar…

And in case that one doesn't convince you either, check out
https://petsymposium.org/2014/papers/Dingledine.pdf

Anonymous

June 30, 2017

Permalink

Torsocks, Torify...

Would it be so difficult to include one or both of these in TBB releases?

I'd also like to know how to configure WGET for use in TBB, whereas in Tails it's already setup.

For putting torsocks into tor browser, I think it's probably better to leave it as a separate tool. That's the unix way, after all, and also most people installing Tor Browser aren't going to ever notice it, and also there are fine torsocks packages for many platforms.

As for setting up your wget to use a socks proxy on port 9150, that sounds like a fine topic for a tor.stackexchange.com question (after you've checked to see if there is one already).

Anonymous

June 30, 2017

Permalink

I fetched and upgraded tor from Tor's repository (hidden service) on Debian 9, stretch:

deb tor+http://sdscoq7snqtznauu.onion/torproject.org stretch main

and it's still version 0.2.9.11-1~deb9u1. Why not 3.0.x series? Or which version to be on apt's repositories is decided by Debian (not Tor Project), and they decide to still stick to 0.2.9??

Download https://dist.torproject.org/tor-0.3.0.9.tar.gz
Extract the tar.gz
CD to the folder that you extracted the tar.gz to.
Use ./configure" command
Then use the "make" command
After that is finished use the "make install" command. And you now should have the latest version installed. You can get future versions from https://dist.torproject.org and you can also get the file signature there.

You get a bunch of great things from the deb package, like having it run as a separate user, having it drop its privileges properly, having logs plus log rotation, and having it set ulimit -n higher so if you configure it to be a relay it won't be broken.

If you want a Tor 0.3.0.x deb package, you can get it from:
https://www.torproject.org/docs/debian

Most people will be happier switching their deb repository, rather than doing the install manually from tarball.

Yep, exactly! Thank guys!

I can manually install the newest stable package (0.3.x) from the tarball if I want, can create the binary package (0.3.x_amd64.deb, for example) too. But as a "regular user", I still prefer to fetch and install/upgrade from the repositories for pretty some reasons, like:

+) Save time (quite a few minutes -- in normal cases, maybe more in unexpected situations)
+) Newest version may required [newer] libraries (especially when the program is pretty large, like hundreds of MB or GB). Upgrading the dependencies, however, may cause problems for other programs which still require the older versions of the libraries.
+) I would trust the Debian/TorProject guys on which version of Tor is the best to used, by using the one from the repository, unless I have very clear and specific reasons to pick a newer version.
+) etc.

Anonymous

June 30, 2017

Permalink

Sorry for the off topic. When should I expect confirmation/rejection about the internship (bridge bw scanner)?

No, there is no Tor Browser update necessary for this issue. It's not clear yet whether we are affected by this problem. If so, we'll think about picking this up if we do a 7.0.3 before the usual security fix update which is planned for the first week in August.

First, asking this question in a blog post about Tor is likely to never reach most Tor Browser people.

I'd suggest asking it on tor.stackexchange.com, where the answer will last longer.

In fact, I bet somebody already has, and can point to the answer here?

In fact, I bet somebody already has, and can point to the answer here?

Yes! Simple "LT" answer: Tor's design document explain this https://www.torproject.org/projects/torbrowser/design/#philosophy in the "5. No filters" section.

More compilcated answer: I should also mention that there's some disagreement between Tor people on this. See ticket 17569 for more discussion. One of the Tor Browser developers Edelstein said: "FWIW, I also like this idea. I think it will help improve privacy, security, performance, and usability."

Tails includes uBlock by default.

My 0.02 satoshis on this is that I'd like to see uBlock by default on the Tor Browser, this will improve performance, and besides that, some of the arguments made: 1) Mike Perry said that one of the reasons he didn't want to ship an ad-blocker was that it would give more incentive for Google to block Tor, but Google certainly does not block the Brave Browser, despite it blocking Google trackers, and using Tor with Google is already a big trouble, indicating that not blocking ads wont change the situation, 2) advertising made on sites to Tor users DOES NOT make sense, I'm from country X and I get an advertisement for a local product (apartment, yoga, ...) that is found only in country Y, they're just wasting money right? 3) Just because Tor Browser already provides strong protection against tracking does not mean other things that block trackers should'nt be added, the situation in the latter case will be much better than in the former.

Anyway, those were just my irrelevant 0.02 satoshis, I still think that they're doing the right choice by sticking to the Tor philosophy of providing true privacy by design without requiring fundamentally and intrinsically imperfect ways such as tracker blocking.

Another thing that is worth considering is adding an addon that bundle common CDN resources, such as Jquery ... sure Tor Browser already protects against them, but there will be a performance improvement. But that's another thing.

If you mean an ETA for the release of Tor 0.3.0.9, it was released when this blog post went up.

If you mean an ETA for a Tor Browser that includes this new Tor version, there is now one as of today (whew -- building Tor Browser is still way more effort than it ought to be).

Anonymous

July 03, 2017

Permalink

!!!WARNING!!! Tor Browser and all VPN services seems blocked in Russia from today! !!!WARNING!!!

bb sweet anonymity.

Anonymous

July 03, 2017

Permalink

I'm using Tor (client only) on Linux. According to man torrc, the options DisableAllSwap and Sandbox could enhance security of Tor, so they shouldn't harm security or anonymity in any way. Would you recommend me to enable them? Do these options have some drawbacks?

Feel free to set them! The Sandbox one might cause some surprise crashes, if Tor does something that the sandbox didn't expect (either accidentally, where a crash is bad, or maliciously, where a crash is good). The Sandbox feature is still experimental, so please experiment with it.

DisableAllSwap is probably also fine, except if you're running a relay and you don't have that much ram, in which case it will turn bad.

Let us know if you learn any lessons from trying them. :)

Which of two choices is more secure?
1. Using sandbox option in torrc
2. Creating restricted file structure in some directory and then running tor via command chroot pointing to this directory. Of course, chroot is called with option --userspec so after changing the root directory for tor process it drops privileges to a non-root user.

My 2 cents:

Actually, chroot was never intended to be security mechanism. It should be used to isolate non-malicious behavior, so you'll not damage main file system tree accidentally. It is in no way related to malicious behavior when application intentionally tries to get out of chroot. If you do have the last case, use either SELinux or virtual machines for forced isolation.

Thank you, Roger! I'll try these options.

The Sandbox one might cause some surprise crashes

The idea of crashes sounds suspicious. It wouldn't be good if core dump with all keys, chains, circuits and the list of visited sites is dumped somewhere on my hard drive, so it can be later found by forensic analysis...

DisableAllSwap is probably also fine, except if you're running a relay and you don't have that much ram, in which case it will turn bad.

I don't use swap on my hard drive anyway, so it shouldn't be a problem.

> The idea of crashes sounds suspicious.

What safe behavior is there, if the daemon is in a state where it is attempting system calls (or file system access) that aren't whitelisted. To be pedantic, the behavior in most cases is that the kernel will `SIGSYS` the daemon, with `SIGKILL` used in some cases.

> It wouldn't be good if core dump with all keys, chains, circuits and the list of visited sites is dumped somewhere on my hard drive, so it can be later found by forensic analysis...

Unless you configure it otherwise, the daemon does this: `prctl(PR_SET_DUMPABLE, 0);`

DisableAllSwap just calls mlockall(). It's totally pointless if you don't have a swap partition.

I don't know Linux internals so well. I'm using standard Debian jessie, and I never change preferences related to creation of core dumps. Am I right that core dumps in Debian are now disabled by default? At least, I never see core files on my system.

Let us know if you learn any lessons from trying them. :)

OK, my comment will be too minor, but still...

I don't map my real IP to my hostname, because... no any program on my PC needs it. It is configured as follows:

  1. # hostname<br />
  2. MYHOSTNAME<br />
  3. # cat /etc/hosts<br />
  4. 127.0.0.1 localhost<br />
  5. 127.0.1.1 MYHOSTNAME<br />
  6. # cat /etc/hostname<br />
  7. MYHOSTNAME

So, somehow MYHOSTNAME cannot be resolved, because 127.0.1.1 is not the IP on any of my network interfaces. Actually, man hostname tells that

  1. -i, --ip-address<br />
  2. Display the network address(es) of the host name.<br />
  3. Note that this works *only if the host name can be resolved.*<br />
  4. Avoid using this option; use hostname --all-ip-addresses instead.

So, the situation when "the host name cannot be resolved" is treated as normal. Since Tor doesn't rely on any DNS system or hostnames, I expect that it doesn't need to mess up with my personal useless hostname. However, if sandbox is enabled, this error is printed:

  1. Jul 04 13:32:19.000 [notice] Tor 0.3.0.9 (git-xxxxxxxxxxxxxxxx) opening log file.<br />
  2. Jul 04 13:32:19.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.<br />
  3. Jul 04 13:32:19.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.<br />
  4. Jul 04 13:32:20.000 [notice] Bootstrapped 0%: Starting<br />
  5. Jul 04 13:32:21.000 [notice] Starting with guard context "default"<br />
  6. Jul 04 13:32:21.000 [notice] Bootstrapped 80%: Connecting to the Tor network<br />
  7. Jul 04 13:32:21.000 [notice] Opening Control listener on /var/run/tor/control<br />
  8. Jul 04 13:32:21.000 [notice] Bootstrapped 85%: Finishing handshake with first hop<br />
  9. Jul 04 13:32:22.000 [notice] Bootstrapped 90%: Establishing a Tor circuit<br />
  10. Jul 04 13:32:22.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.<br />
  11. Jul 04 13:32:22.000 [notice] Bootstrapped 100%: Done<br />
  12. Jul 04 13:34:20.000 [notice] New control connection opened.<br />
  13. Jul 04 13:34:21.000 [err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address MYHOSTNAME! (on Tor 0.3.0.9)

Still, Tor works fine with this err. To avoid it I fixed my /etc/hosts to be

127.0.0.1 localhost MYHOSTNAME

which I think is also fine solution. Nevertheless, I cannot see why sandbox_getaddrinfo needs to be called by Tor.

Sorry, let me add this to my previous two comments.

The error with gethost address is observed only when I start tor-arm (immediately when tor-arm is started, with root permissions). NEWNYM command on ControlPort doesn't force Tor to produce this err. I mean, if tor-arm is not used, I cannot observe this tor log error (independently of the content of /etc/hosts and hostname).

If tor-arm is launched, the error in tor log is observed in all cases, including the case of original configuration (when hostname is resolved to fake 127.0.1.1) and full fix case (when hostname is mapped to my real IP in /etc/hosts). I don't know what tor-arm tweaks in tor process to force him to give this error...

Anonymous

July 03, 2017

Permalink

One question, i have windows 64 bits, and always i had torborwser in 64bits, then since torbrowser 7 and 7.2 7.3
i have torbrowser 32bits, and i have afraid this is only with me,, then i ask. why not is verion 64bits???

Tor Browser has never been a 64bit application so far for Windows users. But we plan to provide it later this year in our alpha series. If everything works out as we hope it'll be available for stable users, too. Maybe already with Tor Browser 7.5 but latest with the switch to Tor Browser 8.

Join the discussion...

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

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