An example of exploiting two fixed vulnerabilities in Firefox on Windows
github.com
github.com
Apologies if you were aware and were talking about some other admin policy. I've run into other devs that weren't aware, so thought I'd share.
1 - https://support.mozilla.org/en-US/kb/choosing-firefox-update...
Firefox having a commitment to ESR means that any changes have to be built in a way that's ESR-compatible. Since mainline Chromium has no such constraints, doing that in a fork will be tough.
It's still an interesting post, but nowhere near as worrying for Firefox users as it sounds.
And their fantastically detailed writeup of a PoC they wrote for that vulnerability: https://doar-e.github.io/blog/2019/06/17/a-journey-into-ionm...
This exploit is different in that they use the arbitrary read/write primitive gained by CVE-2019-9810 to flip a couple of bits and patch out a few instructions with the effect of removing the security boundary between a normal web page and XPCOM. The interesting difference in this exploitation approach is there's no need for ROP chains and shellcode, as you have all the XPCOM components available to use.
Once they're in that privileged context in the content process, they escape its sandbox by exploiting CVE-2019-11708. This works by sending an particular IPC message to the parent process, that causes a web page of the exploiter's choice to load in that process. In this case, the choice is to exploit CVE-2019-9810 again, then use XPCOM components to drop an executable to disk and run it.
Awesome work, and a real pleasure to read, it's satisfying to see such well-commented and clear exploit code.
Other than using a VM or a live distro like Tails , is there any other way for OR users to be safer when running the regular Tor browser bundle, such as by utilising third-party sandbox software?
It wont prevent execution but will prevent escaping to the real os.
https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEna...
"Let’s not get carried away here please, there’s no need to stoke fears about TOR in this instance."
You seem to be jumping to the opposite conclusion with your comment, which I'd argue is an even worse idea with security software. Considering that TBB is based on the vulnerable software package and the vulnerability could directly circumvent what TBB is attempting to accomplish, assuming there isn't a reasonable attack vector seems imprudent, rather than an appropriately measured response.
If I had a serious privacy concern such as reporting on the activity of a government known for murdering its critics, I certainly would think twice if the only thing preventing remote attack code from executing in a vulnerable envrionment on my machine was a browser plugin.
It’s not claiming to be truly secure, but it is several extra layers that an attacker would have to get through
Those people thinking about such topics constantly might not be the average user. I would not feel safe installing Tor on my parents computer and telling them it is safer to do all their browsing now with Tor.
Threat models matter otherwise we'll end up applying wrong security tools: *"use Signal. use tor." when the right thing would have been to meet in person wearing a fake mustache, and keep a pebble in your shoe to change your walk.
GP's advise makes sense for anyone who does not know what Tor is (most people). They are off better if we symlink their "Internet Button" from the desktop to Firefox, install uBlock and NanoDefender for them. If they're still adventurous teach them about creating/editing "multitab containers" (though I bet we've lost most of them by now).
Whether or not someone knows of Tor doesn't influence her threat model or privacy requirements, and therefore doesn't influence what measures can help. Other than that, I agree that you have to be aware of the threat model and what given tools provide.
In addition you should assume that the exit point is owned by an attacker, which means they know which sites are receiving Tor traffic.
The Tor Browser has HTTPS Everywhere which is rather misleadingly named. It still loads stuff over HTTP if it doesn't know of an HTTPS alternative to that particular site. So you should assume that everything you load over HTTP has been trojaned or contains attacks like EgotisticalGiraffe. This applies even if the HTTP site you visit is not compromised or dodgy since the exit node will rewrite content on the fly. https://www.zdnet.com/article/rogue-tor-node-wraps-executabl...
If the site you visit is shady enough then that has also been compromised and is serving you malware over HTTPS. https://thenextweb.com/security/2016/11/11/the-fbi-likely-ra...
Good luck with the sandbox https://venom.crowdstrike.com/
If you assume both, it's already game over because you can be deanonymized by traffic correlation attacks. At that point you might as well be using a VPN.
- Beyond the US, China and Russia might have the resources and enough of an interest to undermine TOR. Everyone else has lots of other, lower-hanging fruit to attack first. I've had some interaction with Germany's efforts about a decade ago, and I wouldn't be surprised if their largest project back then is still ongoing, which was migrating away from Windows 95.
- More nation states trying to attack TOR would probably lead to increased security, because the only known weak point is controlling both exit and entry nodes.
- None of these agencies outside of 5-eyes plus maybe Israel & NATO would ever collaborate on something like this.
- Your drug, porn, or even whistleblowing habits aren't even interesting enough to warrant investment in far more obvious avenues of investigation. If, for example, you semi-regularly buy a few hundred $ worth of bitcoin with your credit card but don't report/have any holdings, you're probably not spending it at the one or two remaining legal online stores accepting it.
- Heck, there is some guy apparently working in the Trump administration, publishing an anonymous book this month. Considering we're probably talking about Harvard Law and not MIT grad here, and that the Prez isn't exactly known for letting strategic considerations get in the way of his gut instinct to exact revenge for personal slights, every day this person isn't outed is a pretty good argument against the tendency to consider the US security apparatus to be all-mighty.
- In the alternative, if they are unwilling to compromise their methods for that target, you will probably never make it to the level where they would be willing to do it for you (sorry).
- The same argument applies to all the dark markets, where history suggest retiring with a bunch of your customers' cash is just about as likely as somehow being caught. Most prosecutions also happened outside US jurisdiction, making me doubt suggestions of parallel construction.
I wonder why is the privileged parent process even allowed to execute unsigned Javascript from the network? IIRC it already has eval support turned off. I get that it's hard to get rid of privileged Javascript completely (Servo thankfully made the choice early on to not do that at all), but is there any feature that requires downloading & executing Javascript from the network in the privileged parent process?
There is the Subresource Integrity mechanism (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) as a stopgap for this but it doesn't really provide something useful in this case because the load target has to be known in advance and you can't provide a hash for top-level content in the URL.
https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...
https://www.mozilla.org/en-US/security/advisories/mfsa2019-0...