InformAction Forums

Hi,

I noticed that in the changelog of Firefox 38 there was a security fix involving SVG and CSS.

CVE description:

Heap-based buffer overflow in the SVGTextFrame class in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 allows remote attackers to execute arbitrary code via crafted SVG graphics data in conjunction with a crafted Cascading Style Sheets (CSS) token sequence.

Would that code have executed with NoScript enabled ?

Also wondering about use-after-free during text processing with vertical text enabled, which "allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a document containing crafted text in conjunction with a Cascading Style Sheets (CSS) token sequence containing properties related to vertical text."

It doesn't seem to require JavaScript, in which case NS would not protect against it, but I can't be sure.

Berk wrote:It doesn't seem to require JavaScript,

How are you determining that?

I'm not sure like, at all, but my vague understanding is that once you've triggered a buffer overflow, use-after-free or some other vulnerability, the code you are allowed to run is not supervised by NoScript (in our case), and possibly is not even JavaScript because you escaped *something* and are running code in some other context.

To trigger these in the first place you most often do need JavaScript, but both CVEs make no mention of scripting, they're talking about either a text+CSS combo or a SVG+CSS one. I don't know if JavaScript is necessary on top, that's what I'm wondering.

Ideally I could figure this out alone with some rule of thumb that would fix my concerns from 1st paragraph, but my understanding is way too vague at this point.

Most of these vulnerabilities actually do require JS to exploit even if it doesn't say so in the CVE description.
Giorgio has access to the security-sensitive bugs (& PoC's therein), and given his track record, if he thought there was need for NoScript to protect against something it doesn't already cover, he'd implement it. So without more information, I don't think there is anything to worry about.

It's not that I worry, I would like to understand how this works technically, and if NoScript can really protect against all abuses from buffer overflows, use-after-free and such vulnerabilities, assuming the most secure NS configuration rather than the default one, and no resource allowed, i.e. no JS obviously, but no MP4 and no font either.

From CWE:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.

Wouldn't it be possible to have the new allocation be a simple string that happens to be code that has no chance to be executed as-is, because Firefox knows it's just a string, except a use-after-free ends up pointing to it in a way that Firefox doesn't know anymore it's a string or something, and it ends up being executed as JavaScript in a context not controlled by NoScript ? (since Firefox itself lost it)

Well, it's typically quite difficult to set up such a scenario (writing a value, improperly cleaning up the pointer, writing a chunk of shellcode to the old address, then triggering reuse of the address) without the use of JavaScript. Maybe there is a weakness in a particular function related to processing of SVG - but without JavaScript, how do you make Firefox call that function? How do you ensure that your shellcode will be written to the right place at the right time - especially if you want to bypass protections like ASLR/DEP? HTML alone just doesn't allow that kind of power in 99% of cases.

Note that the SVG/CSS flaw specifically noted that it is usually not a risk in Thunderbird because scripting is disabled. I'm not sure about the vertical text one.