SoylentNews is people
SoylentNews
A company that sells exploits to government agencies drops Tor Browser zero-day on Twitter after recent Tor Browser update renders exploit less valuable.
Zerodium, a company that buys and sells vulnerabilities in popular software, has published details today on Twitter about a zero-day vulnerability in the Tor Browser, a Firefox-based browser used by privacy-conscious users for navigating the web through the anonymity provided by the Tor network.
In a tweet, Zerodium said the vulnerability is a full bypass of the "Safest" security level of the NoScript extension that's included by default with all Tor Browser distributions.
NoScript is a browser extension that uses a whitelist approach to let the user decide from what domains the browser can execute JavaScript, Flash, Java, or Silverlight content. It is included with all Tor Browser distributions because it provides an extra layer of security for Tor Browser users.
Zerodium's Tor zero-day basically allows malicious code to run inside the Tor Browser by bypassing NoScript's script-blocking ability.
(Score: 2) by bob_super on Tuesday September 11 2018, @07:02PM (1 child)
Thanks for the write-up. I kinda knew that, but the subtext is the same as for the somehow-still-a-thing buffer overflow attacks: I don't want to execute this data. Just don't. Never pass this address to the PC or copy this data into a place where it could get executed. Period.
Which is too much to ask of an extension, and should be in the browser engine itself: read and interpret the page, but never ever run any script that goes beyond basic formatting (list the explicit safe objects which can be manipulated) in there without my explicit permission. Leaving me with mostly borked internet pages, a non-starters since that turns off >98% of users.
(Score: 3, Informative) by DannyB on Tuesday September 11 2018, @09:00PM
Buffer overflow attacks would be a thing about using a low level language, like C, and programing techniques where you pass addresses without lengths, or don't properly do length checking. A problem far removed from what is being described at the high level.
NoScript doesn't have control of how the browser processes the byte stream once NoScript allows the browser to process it. I haven't seen NoScript's source code, nor how it interfaces with the browser. I suspect it basically works like this. NoScript gets the incoming info, and can decide whether to hand it to the browser or not. Potentially NoScript can edit the content, and hand it to the browser. Whether it can edit it, I do not know, and is not so important to understand the problem.
If NoScript decided it is not interested in the content, and does not need to block it, then it hands the byte stream to the browser which processes it -- including exploits that happen within the browser, or other browser plugins, if any.
So NoScript sees this Content-Type, doesn't know to check it, or edit it, for JavaScript content, and hands it to the browser. The browser then handles the content as it would whether or not NoScript was installed.
Basically, NoScript has veto power, or possibly censorship editing power over byte streams, and will take actions on certain types of content.
The lower I set my standards the more accomplishments I have.