InformAction Forums

Hi users of the NoScript extension for Fx,

The renewed Milw0rm site to-day published a new heap spray hole for Firefox 3.5 enabling attackers to get complete control over the browser via a buffer overflow through memory corruption caused by an error in handling "font" HTML tags The vulnerability has not been patched yet, F-Secure free beta Exploit Shield protects against this vulnerability: http://www.f-secure.com/en_EMEA/support ... -programs/
Does NoScript protect us for this spraying of the heap? Can we get confirmation of this protection?
http://www.web2secure.com/2009/07/mozil ... spray.html
The vulnerability is caused due to an error when processing JavaScript code handling, if that is so I think I do know the answer to the above question, and I guess the answer will be affirmative - Yes, NoScript protects here. Am I right?

luntrus

If this is the same vulnerability, Mozilla Firefox Memory Corruption Vulnerability, then someone posted, yes, NoScript protects.

I looked here, http://hackademix.net/, but saw nothing mentioned.

Looks like it is the same.

SeaMonkey 1.1.17 seems unaffected (with NoScript).

SeaMonkey 2 seem unaffect with NoScript & file:// NOT Allowed.

SeaMonkey 2 brings up an Unresponsive Script warning with NoScript & file:// Allowed.
Stopping the script at that point does just that. Hitting Continue looks to loop back to the Unresponsive Script warrning.

Quite an old build, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 SeaMonkey/2.0b1pre, so you would think it to be vulnerable.

Lets disable NoScript & see ...

Same results, Unresponsive Script warning.

The quoted section is wrong. See below...

Yes it does.

I may have made the POC incorrectly as I can't force a crash?

@therube
Have you got JIT disabled?
Setting the javascript.options.jit.content about:config preference to false mitigates this bug, since it is a TraceMonkey vulnerability.
Firefox 3.0.x/Seamonkey 1.1.x and below are unaffected because they've got no JIT compiler.

True (on both counts).
No JIT in SeaMonkey 1.1.17, thats a given.
And javascript.options.jit.content is set to True.

I'll have to try to redo my POC later.

Hi therube,

If you will do so, then NoScript will work like a charm, successfully detecting the PoC’s attempt to access file://,

luntrus

Does NoScript protect because it prevents the JavaScript from running (site not allowed) or does it prevent a bad script from an allowed site from performing the buffer overflow? In other words if a site I "allow" has let me down and allowed bad scripts to be installed on the site will NoScript guard against the bad script?

The former.
If a site you Allow has let you down (assuming the exploit code is hosted on that site & not at some other domain), well, you will be let down.

I don't know what I did earlier, but surely messed up the POC.

Just redid it & now I'm crashing like good little browser should.

NoScript blocks the exploit, because it relies on JavaScript. Just as simple as that.

Allowing file:// in NoScript & you crash.
(file:// because my POC happens to be local, on my computer.)

Toggling the Preference item, javascript.options.jit.content, from true to false will block the exploit in the interim.

Hi therube,

The work-around for this will negatively influence the performance of the fx browser, so working NoScript is the better and more natural option for us until this is fixed, at least that is my two cents.
"The exploit portal Milw0rm has published an exploit for Firefox 3.5. The exploit demonstrates a security vulnerability by starting the Windows calculator. In testing by heise Security, the exploit crashed Firefox under Vista, but security service providers Secunia and VUPEN confirmed that attackers using prepared websites can infect PCs. The cause of the problem is a buffer overflow when processing specially prepared Font tags."
http://www.h-online.com/security/First- ... ews/113761
Is this vulnerability a platform independant or a windows-specific firefox bug?

luntrus

The work-around for this will negatively influence the performance of the fx browser

Bullhockey. Yes what you say is true. Would you have noticed the difference though? Perhaps if you were looking for it?
(I didn't check, but my feeling is, you would never know if it were set one way or the other.)

The exploit demonstrates a security vulnerability by starting the Windows calculator.

That may depend on your OS revision level. (Posted elsewhere) it said XP SP2, calc opened. XP SP3, the browser just crashed (which is what I observed).

Is this vulnerability a platform independant or a windows-specific firefox bug?

Not sure?

I used Ollydbg to attache the process but failed to trigger the exploit .Everytime I did such work ,I can only see the collapse of Firefox.The only way could I trigger the shellcode is in such kind of method.First , open a firefox.Second, open Ollydbg and open an excutable firefox process,run it.Third it will present a new windows and the ollydbg stops at address 7c92e54 .Forth, open the Html ,trigger the shellcode but the Ollydbg can show nothing.......Windbg the same......I wonder if you can tell how to deal with it.

luntrus wrote:The work-around for this will negatively influence the performance of the fx browser, so working NoScript is the better and more natural option for us until this is fixed, at least that is my two cents.

I disagree. The exploit is completely avoided by disabling JIT, i.e. JIT has a known, exploited vulnerability and should not be used until it's fixed. This is what's recommend by the Mozilla security team: Critical JavaScript vulnerability in Firefox 3.5. Disabling JIT is "the better and more natural option for us until this is fixed". The vulnerability has already been fixed in the development builds for the next release, Fx 3.5.1, which I hope will be released soon. https://bugzilla.mozilla.org/show_bug.cgi?id=503286#c57

I've disabled JIT according to Mozilla's recommendation by setting the javascript.options.jit.content pref to false. I haven't noticed any performance degradation. But even if I did, I wouldn't want to use a browser that's "twice as fast" when the price is a known, exploited vulnerability. I'm certain the developers wouldn't consider that a reasonable trade-off either. YMMV.

NoScript won't help you if one of your trusted sites has been hacked. Why take a chance when we have a rock-solid workaround? Just turn off JIT until the vulnerability is fixed. BTW, javascript.options.jit.chrome needs to be set to false too, but that's the default value.

Content deleted.
Off topic.