Brisco wrote:Thanks for the reply. I can't access vulnerability bugs on Bugzilla so I can't check the PoC, but I'm glad to hear such bugs require JavaScript to be exploited.
So if someone with Firefox 35 (vulnerable to this CSS attack) visits a malicious site where JavaScript is blocked, nothing happens ? Or does the browser crash but the crash is not exploitable ?
Nothing happens. Programmatic, dynamic (JavaScript-driven) CSS changes are required to trigger this specific bug.
Brisco wrote:
And more generally, if a vulnerability in the CSS parser allows arbitrary code to be ran, does the code that escapes the parser have to be JavaScript subject to NoScript rules ? Like, if the parser is written in C++, wouldn't it be C++ instead, or some other caveat that makes it live outside of NoScript's watch.
It can't be said "more generally".
For instance, if a buffer overrun in the parser can be triggered by feeding it some carefully crafted static payload, there's likely no need for JavaScript to exploit it and NoScript won't protect you. Fortunately these kinds of bugs are becoming rare, especially in areas like HTML or CSS parsing where the technology is old and well understood: even if, as you said, new features are being added, the should have limited or no impact on the core parser structure, at least if engineering is done correctly. The situation should become even brighter with Servo, the new Mozilla browser engine which is being written in Rust, a new programming language designed from ground up to be much safer than C/C++, yet as performance-friendly and low-level as possible.
Different is the case for relatively recent stuff "ported" on the Web from environments which used to be generally regarded as "trusted", and whose parsers are therefore less resilient to hostile payloads: for instance, fonts (as in Web Fonts) and 3D rendering (as in WebGL), which in facts NoScript provide with dedicated restrictions facilities.
