New Release: Tor Browser 8.5.3

by boklm | June 21, 2019

Tor Browser 8.5.3 is now available from the Tor Browser Download page and also from our distribution directory.

This release includes an important security update in Firefox, a sandbox escape bug, which combined with additional vulnerabilities could result in executing arbitrary code on the user's computer.

Note: As part of our team is currently traveling to an event, we are unable to access our Android signing token, therefore the Android release is not yet available. We expect to be able to publish the Android release this weekend. In the meantime, Android users should use the safer or safest security levels. The security level on Android can be changed by going in the menu on the right of the URL bar and selecting Security Settings.

Update: The Android version is now available from the download page.

The full changelog since Tor Browser 8.5.2 is:

  • All platforms
    • Pick up fix for Mozilla's bug 1560192
Tags
tor browser
tbb
tbb-8.5
Anonymous

MakeTBBGreatAgain (not verified) said:

June 21, 2019

Permalink

Can you guys please just add the HTTPS-Everywhere and NoScript icons on the top bar (where the Tor Button is) by default? It's a pain to customize and set them up each time. Those addons are important enough that they belong there.

Also someone really needs to tell noscript to put a link to their options somewhere on their menu because right now the only way to get to it is from the firefox addons menu, while everything else about noscript is customized from their toolbar icon directly.

https://blog.torproject.org/comment/281883#comment-281883
https://blog.torproject.org/comment/282317#comment-282317

> the only way to get to [NoScript options] is from the firefox addons menu, while everything else about noscript is customized from their toolbar icon directly.

Click the NoScript toolbar icon. Along the top edge are a bunch of large icons. Hover your mouse on the NoScript icon that has a white wrench on it, and the popup tooltip will say, "Options..." Click it.

Those buttons never disappeared for me. This is what the navigation bar looks like for me with no customizations:
[======= Page URL =======] [O] [S] [== Search ==] [NS] [HE]

O = Onion
S = Shield
NS = NoScript
HE = HTTPS Everywhere

In recent versions for Linux including 8.5.3 I see this:

[======= Page URL =======] [O] [S] [== Search ==] [NS] [HE][M]

M = Drop down menu

No NS or HE in view.

Are you using the Windows version?

It cannot be good that the versions apparently differ.

OK. I did install from a new tarball in my Debian.

I also use Tails, usually booted from a DVD, but I also use Tails booted from USB sticks. And I upgraded those by cloning the running Tails (the latest booted from the DVD burned from the verified ISO image). And in those I do not see the icons. Is it safe to clone the running Tails from an instance of Tails booted from DVD burned from verified ISO image? If you cannot be entirely sure someone has not had physical access to the laptop?

If the hardware is compromised, any software that runs on it may become compromised regardless of if it was verified. Turn off the device completely, and unplug all non-essential parts outside and inside the case. If software is all you're able to work with, begin by reflashing the firmware/BIOS of each hardware component from verified copies of the firmware and flashing program. Then, run your live DVD on it and go from there. Don't reflash unless you absolutely have to because it's possible to brick the hardware, and flash memory has a limited number of erase-write cycles.

Running the verified DVD, mount the clone, and compare partition parameters in Gparted of the verified DVD to the mounted clone.

When you boot the DVD, does the bootloader menu list an option to check the CD/DVD integrity as it does in Ubuntu for instance? What you could do is find the file of checksums/hashes (that the integrity checker uses) on the verified DVD and compare the sha512sum of that file to the sha512sum of the file of the same name in the clone mounted while running the verified DVD. Or you could make your own checksum/hash file of all files on the verified DVD by running sha512sum on the root directory of directories on the mounted verified DVD. Mount the clone, cd to the clone's root directory, and input your checksum file to sha512sum to check all files of the clone.

Ask Tails developers. It's a difficult but important question.

>Are you using the Windows version?

No, Linux also. Mine is the same w/ the hamburger menu on the right.

The placement of the onion and shield buttons is weird but it doesn't matter apparently.

Anonymous

Anonymous (not verified) said:

June 21, 2019

Permalink

Thank you all so much for your rapid action!

However:

> As part of our team is currently traveling to an event, we are unable to access our Android signing token, therefore the Android release is not yet available.

An unneccessary delay of even a few days could be very serious once more people adopt the new Tor for Android. While I appreciate that TP is a small outfit (in many ways that is a strength), I and others have urged TP to plan ahead for emergencies such as this pair of critical zero-days seen to be be currently jointly exploited in the wild on very dangerous cyberattacks. With particular respect to travel, users have suggested that TP designate a "Tiger Team" which does not travel and which can handle this kind of emergency just as fast as Mozilla or whomever issue any needed "upstream" security patches.

I don't know exactly how their team set it up, but a token is basically a sealed hardware device made to be unique. A PGP subkey can be created and given a new passphrase, but creating subkeys all the time clutters and inflates the size of keys shared on keyservers. I'm guessing TP has better and safer approaches, too. In other words, it might be a sign of good security practices that they aren't able to access it.

I assume TP uses ssss (Shamir's secret sharing scheme; see the Debian repositories) as part of their solution. AFAIK this should be a very secure way of allowing any subset of k devs to mutually sign something which needs to be signed, but accessing while traveling is no doubt a harder problem even if devs keep their devices on their persons at all times, because borders.

I agree with that. The problem in this particular case is that we did not have the chance yet to move our signing token to our signing infrastructure which is not dependent on a single person being available. This is done in the coming weeks. Thus, this problem should not occur again.

Good to know, thanks, GeKo. And thank to the entire team for quick action on this zero-squared day.

BTW, I'd also like to offer huge thanks to the Tails team for their own rapid action. I know they planned to spend the weekend making intensive final preparations for the rollover from Stretch to Buster as Debian stable which is expected to happen sometime around 7 Jul 2019. So last weekend must have been pretty stressful.

I hope everyone get's a vacation, staggered of course so there are enough people to handle any emergencies.

Has anyone else noticed intense cyberattacks apparently associated with 21 Jun? I have every year since 2013. Which I interpret as weak evidence pointing to FVEY. But there's always something new, such as the alleged IR wiper attacks, so who knows?

Anonymous

pelethar (not verified) said:

June 21, 2019

Permalink

Hi - can anyone talk me through how to change the country it thinks I'm connecting through when using 8.5.3? The instructions I've been able to find all refer to editing the text in the "torrc" file - but when I open that up, it's completely empty. I've run Tor several times since the update so that's not the reason.

Normally, your torrc.orig.1 file always will have no content. Normally, your torrc file always will have content. Your current Tor Browser installation could be corrupted if your torrc file has no content

You might resolve the issue if you (1) download a fresh Tor Browser installer package from http://expyuzz4wqqyqhjn.onion/download/languages/ (or, https://www.torproject.org/download/languages/), (2) completely uninstall your current Tor Browser installation per the instructions at http://dgvdmophvhunawds.onion/uninstalling/ (or, https://tb-manual.torproject.org/uninstalling/), and (3) install the fresh download.

After content appears in your new torrc file, you can change/select the country location(s) of your exit relay per the Tor Project options:

https://support.torproject.org/tbb/tbb-16/

https://2019.www.torproject.org/docs/faq.html.en#ChooseEntryExit

Caveat: "We recommend you do not use these [options] — they are intended for testing and may disappear in future versions. You get the best security that Tor can provide when you leave the route selection to Tor; overriding the entry / exit nodes can mess up your anonymity in ways we don't understand."

I don't know if people notice it or not, but tor browser can be downloaded from http://yjuwkcxlgo7f7o6s.onion/tor-package-archive/torbrowser/8.5.3/ without going through exit node (the download links in http://expyuzz4wqqyqhjn.onion/download/languages/ are still in the clear net)

For the record, tails can be downloaded from http://yjuwkcxlgo7f7o6s.onion/amnesia.boum.org/tails/stable/tails-amd64… too.

All links above are listed in https://onion.torproject.org/ so they should be genuine.

Anonymous

Asterix (not verified) said:

June 21, 2019

Permalink

Tried several times to update (get that green arrow in top-right corner) but everytime the history say 'install failed'. ...?!...
The last installed was 8.5.1. (20190307020101).

Are you installing Tails to a bootable USB with a persistent volume holding your personal data? If so, if you know how to obtain the latest Tails (the ISO image), do that (it is about 1.4 GB so it will take a little while), burn a bootable Tails DVD, boot Tails on a 64 bit laptop (with suitable boot settings so it boots from the DVD drive before the disk drive), insert but do not mount your existing Tails USB, and from the top left of Tails menu bar, choose

Applications -> Tails -> Tails Installer

Check the boxes saying you want to clone the running Tails to the (unmounted) USB drive. You should see a message saying the installer will update Tails while preserving the persistent volume. Confirm that by choosing "Update". After about five or ten minutes your USB should be updated and you should be ready to boot your laptop from the USB.

I've tried other ways to use the Tails installer to upgrade Tails USBs but like you have not been able to make them work properly. But so far the method I just described has always "worked" in the sense that I can boot from the USB and I can mount the persistent volume. I do worry about cloning a live Tails from the code as it exists in RAM rather than the code as it exists on the DVD, since there is always the niggling worry that they might not be the same--- which would be bad because I've only verified the DVD not Tails as loaded into RAM. NSA/TAO and thus UAE/DarkMatter operatives just might be able to mess with the controllers for disk drives--- if they had brief access to the laptop in a hotel room or at a border, for example--- to do something horrid as Tails is read from the DVD. And if they don't yet know how to do this I have no doubt they are trying to figure out how to do this. To you and me. Nationality and good citizenship are irrelevant to these professional poisoners.

By the way, using Tails booted from a DVD should be more secure (at least assuming the DVD is R/O), but Tails booted from a USB is possibly more convenient because you can install persistently a small number of small applications (but you should avoid installing complicated software which has many dependencies and probably opens many security holes). If you do boot Tails from a DVD, you can keep your personal files on a LUKS encrypted USB data stick, which you can easily create using Tails itself. So using Tails booted from a R/O DVD is practical and as the recent flurry of exploitable critical vulns plus speculative execution style attacks suggests, may be wiser than using Tails booted from a USB.

Asterix never said they use Tails.

> I do worry about cloning a live Tails from the code as it exists in RAM rather than the code as it exists on the DVD

Everything passes through RAM so the CPU can process it. That includes between connected peripherals. Peripherals do not talk to one another directly; the CPU manages data bus communication. Input/output peripherals except for video cards connect to a motherboard's south bridge; CPU and RAM are on north bridge.

> Asterix never said they use Tails.

Oh damundblast, you are right, my mistake, sorry, everyone.

Sounds like you know a lot more about bare metal than I do but the Snowden leaks confirm that state-sponsored malware targeting disk drive controllers (not the CPU) are a thing. Unfortunately.

Not sure I see your point but it may be relevant that one of the fixes in the most recent Tails was a fix made upstream in Debian for a critical vulnerability in dbus (the Debian package which handles the data bus).

Does anyone know whether it is presumed safe to upgrade a Tails USB by cloning from a running Tails, booted from a R/O DVD burned from a verified ISO image? I'd follow the instructions at talls.boum.org but my Tails TB literally cannot read their tutorial so I don't know what procedure they advise. But I've found by trial and error that cloning (and nothing else) always seems to work and it also faster for me.

Do you have Tor Browser customized in some way? On which operating system does this happen? If you enable update logging by setting app.update.log to true in your about:config and opening the browser console before performing an update e.g. by pressing Ctrl + Shift + J do you see some errors showing up? (You can force an update check by opening the about dialog in Tor Browser by clicking on the Hamburger menu -> Help -> About Tor Browser)

Please immediately remove the obfs4 bridge IP address appearing in your submission. An adversary could use the obfs4 IP address appearing in your submission to identify the physical location of the bridge relay, attack it, compromise it, or take down the volunteer operator of the obfs4 bridge relay, who might not want an adversary to know his physical location and his identity.

In future, you should avoid mentioning the IP address of a bridge in public, for reasons which will presumably become obvious once you remember why we need bridges in the first place.

Sorry I can't help with your question but I hope someone else will answer it.

The obfs4 bridges are listed in the file torrc. On my Mac the file produces 13 OBFS4 bridges and there IP when I deleted the file the same obfs4 files appeared with a change in order.

Explain how displaying the IP protects the obfs4 bridge site when anyone can view the torrc file?

The torrc file is a local one on your computer, so it is not readable by anyone but you (and maybe your admin). That said, the default bridges we ship are kind of public anyway as they are included in our source code which is public.

Your obfs4 bridge line (and its IP address) will not change unless you replace your bridge line with another bridge line. However, if your Tor Network Settings includes 2 or more bridge lines, your bridge line (and its corresponding IP address) automatically can/will change if your current bridge stops running, one or more other bridge lines are present (in reserve) in your Tor Network Settings, and if that/those other bridge(s) are running.

> Should the circuit Bridge obfs4 IP change occasionally ?

Not unless you can't access them, they are being attacked or compromised, or they do not have the "Valid" flag in relay search. As long as bridges remain valid and secret, there is less reason for a user's tor exe to choose a different bridge than there is to choose a different public guard node. You should occasionally check the validity of your bridges by pasting the hashed fingerprints in relay search because a user's tor exe doesn't automatically choose new bridges if their flags change. No doubt some users connect by old, neglected bridge settings. Developers(!), would it be safe if tor automatically checked a user's old bridges?

If python is installed, type on the command line to convert a fingerprint into a hashed fingerprint:

  1. <br />
  2. python -c 'import binascii; import hashlib; fingerprint = "0123456789ABCDEF0123456789ABCDEF01234567"; print("Hashed fingerprint: " + hashlib.sha1(binascii.a2b_hex(fingerprint)).hexdigest().upper())'</p>
  3. <p>

Replace 0123... with the fingerprint. Developers(!), it would be better if a converter was built into onion icon >> Tor Network Settings.
https://blog.torproject.org/comment/281627#comment-281627

Another thing to be mindful of is the country and company where your bridge IP is. (Developers(!), Tor Browser's circuit display doesn't show your bridge's country.) Copy the IP to a local, non-cloud text editor. Change the last three to four digits of the IP to obfuscate the true IP (octets are 0 to 255 decimal in IPv4, hextets are 0 to ffff hexadecimal in IPv6), and then copy the obfuscated IP into a geolocation search engine in Tor Browser. Keep all true, non-hashed bridge information private, secret, and on your local machine.

The issue is the tor browsers Bridge obs4 IP XX.XX.XX.XX, Cogent is reporting "connection is not secure" for Https valid connection occasionally and since the Obsf4 bridge does not change often from what I understand I thought I would report the issue.

Since Tor is experiencing a problem with bridges obfs4, FTE IPv6 and emailing of new bridges I want to ensure Tor is aware of the additional issue.

> Cogent is reporting "connection is not secure" for Https valid connection occasionally

If this started in last few days, could it be related to the latest huge BGP snafu in which Verizon improperly sent 20% of major East coast website traffic through a tiny regional ISP (used by CIA?) which immediately crashed under the load, so all those packets were sinkholed. Maybe an IR cyberwar action? I believe Cogent is much used by US feds, so this just might be an explanation.

> Cogent is reporting "connection is not secure" for Https valid connection occasionally

Hypothesis: the exit node needs to perform OSCP lookup to connect to your destination website. But over the weekend, a good deal of traffic (I am guessing including some Cogent too) was improperly sinkholed owing to a BGP "mistake" (or was it? Cf. alleged IR-US cyberwar in progress). So maybe the https connection failed because the exit node could not do the cert lookup in time, because that request was sinkholed owing to the BGP "goof".

The regional ISP affected by the BGP "goof" may be a provider for federal USG agencies so it would not be implausible that the "mistake" happened because IR cyberwarriors broke into the network of that small ISP and made the improper claim which was accepted by Verizon resulting in a huge mess for much US traffic.

I have noticed that obfs4 bridges are no producing three new bridges for obfs4 that work as of June-27-2019.

However I have noticed cross script errors which when I perform a captcha will continue to repeat.

You are not supposed to request new bridges or change them if you already have ones that work. The system is designed to prevent people from collecting the whole list.

Anonymous

Cynthia Marmont (not verified) said:

June 21, 2019

Permalink

Please address the code signing issue with Android.

If one or more of your team are ran over by a car then the project has severe issues. This is not good for project continuance.

Thanks for all your efforts so far!

> If one or more of your team are ran over by a car then the project has severe issues. This is not good for project continuance.

This is exactly the problem with Shamir's Secret Sharing System (see the software Debian repositories) can help solve. I am pretty sure Tor Project knows all about ssss and uses it-- I know the Tails team does.

But yes, plus one on making

a) proper code signing

b) preparing for crises in advance

top priorities.

Speaking of Shamir's secret sharing scheme, guess who else uses that? Cloudflare!

See their online randomness source:

https://www.cloudflare.com/leagueofentropy/

It would be very interesting to subject the output streams to statistical tests which challenge the alleged cryptographic quality randomness.

One of the uglier USG schemes to mess with other nations involved destructive weather alteration and destructive earthquake generation. Those who know the mindset of military contractors who sense opportunity for a new boondoggle will not be as quick as some to dismiss the concern that using seismic data from Chile might start a very bad actor thinking about altering the data stream by generating earthquakes. Especially because that ability would take out 3 of the 5 servers in sufficiently destructive quakes, because all three live in some of the most dangerous fault zones in the world.

Speaking of Debian, guess who else uses their own derivative of Debian? The Russian government! (Search for "Astra".) Just one more reason to be concerned about NSA messing with Debian: to attack Astra, it is natural to begin by attacking Debian. Thank you, Kremlin. Brrr!

One wonders whether Kaspersky will pay more attention to Debian specific state-sponsored malware because the Russian government asks them to help protect Astra.