CSS vulnerabilities

[Brisco]

Hi,

CSS has evolved a lot in the past 7 years. I was wondering, can NoScript do something to protect Firefox CSS vulnerabilities from being exploited like it does with JavaScript ? Example CSS vulnerability: https://www.mozilla.org/en-US/security/ ... sa2015-20/

[Giorgio Maone]

You can block CSS inclusions with ABE, but inline CSS will be parsed anyway.
However, bugs like this need JavaScript to be effectively exploitable (see the PoCs attached to the bug report), so NoScript already protects you.

[Brisco]

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 ?


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.

Sorry for the lack of good terminology and the fuzzy description, I'm no expert in security as you can see
I'm curious to know more now that CSS is getting more complex features.

[Giorgio Maone]

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.

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.

[Guest]

That settles it for CSS then! Thank you for this thorough explanation

Fonts are important to block by default but now that everyone uses them we end up with weird characters that don't make sense all over the place. I wonder if Mozilla intends to ever rewrite the font library so it can be enabled safely like CSS and SVG.

[Thrawn]

If you're really concerned about CSS, then you'll have to go with a different browser, like Dillo or Links.