Javascript exploit actively used against TorBrowser
As much as I love Mozilla and their philosophy, it has to be said that - if you have any sort of worries about security - using Firefox is a bad choice and borderline reckless.<p>It lacks even basic exploit mitigations that other browser have had for years now (most importantly a feature-complete sandbox).<p>Right now, Firefox is just a single process with zero separation of privileges. Any bug in the rendering code is a potential RCE. Writing exploits for Firefox vulnerabilities is well within a strong amateur's reach and this headline does not surprise me at all.<p>This is a (probably incomplete) list of all public exploits in the past three years:<p>- 2013/08: XPCOM RCE (<a href="https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_svg_plugin.rb" rel="nofollow">https://github.com/rapid7/metasploit-framework/blob/master/m...</a>)<p>- 2013/08: __exposedProps__ (<a href="https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_proto_crmfrequest.rb" rel="nofollow">https://github.com/rapid7/metasploit-framework/blob/master/m...</a>)<p>- 2014/03: WebIDL RCE (<a href="https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_webidl_injection.rb" rel="nofollow">https://github.com/rapid7/metasploit-framework/blob/master/m...</a>)<p>- 2015/03: PDF.js RCE (<a href="https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/browser/firefox_pdfjs_privilege_escalation.rb" rel="nofollow">https://github.com/rapid7/metasploit-framework/blob/master/m...</a>)<p>- 2015/08: The file stealing exploit: <a href="https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/" rel="nofollow">https://blog.mozilla.org/security/2015/08/06/firefox-exploit...</a><p>- [The FBI exploit (2016-ish)]<p>- This one.<p>Publicly known as in, <i>with a fully functional Metasploit exploit</i>, and most of them through JavaScript, so 100% reliable. ASLR isn't going to help with interpreter bugs. This is 90s level bad!<p>And those are just the publicly known ones. With a code base as large as Firefox, it'd be foolish to assume to assume that there aren't any private 0days. Just take a look at this list:<p><a href="https://www.cvedetails.com/vulnerability-list/vendor_id-452/product_id-3264/Mozilla-Firefox.html" rel="nofollow">https://www.cvedetails.com/vulnerability-list/vendor_id-452/...</a><p>Even Microsoft Edge is better at this.<p>Project Electrolysis is a step in the right direction, but it will take a LONG time to mature. Last time I checked, it was just for process separation and did not provide any security guarantees. Chromium had a fair bit of sandbox escapes during the first years, and there's no reason to believe this is going to be different with Firefox. If have high hopes for their Rust re-implementation, but that's not going to be usable any sooner.<p>In the meantime, there's nothing like Chrome/Chromium security-wise. Not even close.<p>When was the last time there was a reliable, public Chrome exploit with a sandbox escape? The only one I can think of was the Hacking Team exploit, which used a Windows kernel 0day to escape the sandbox.<p>Chrome's security team is probably the strongest in the industry and they poured an absurd amount of effort into Chrome's security. And it being open source means that I can use without worrying about backdoors or data leakage.