Page 1 of 3

New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 8:15 pm
by luntrus
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

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 8:19 pm
by therube
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...

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 8:44 pm
by Giorgio Maone
Yes it does.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 8:48 pm
by therube
I may have made the POC incorrectly as I can't force a crash?

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 8:59 pm
by Giorgio Maone
@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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 9:07 pm
by therube
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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 11:00 pm
by luntrus
Hi therube,

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

luntrus

Re: New heap spray vulnerability- does NoScript protect?

Posted: Tue Jul 14, 2009 11:14 pm
by Jim Too
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?

Re: New heap spray vulnerability- does NoScript protect?

Posted: Wed Jul 15, 2009 12:36 am
by therube
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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Wed Jul 15, 2009 12:42 am
by therube
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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Thu Jul 16, 2009 12:15 am
by luntrus
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

Re: New heap spray vulnerability- does NoScript protect?

Posted: Thu Jul 16, 2009 12:45 am
by therube
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?

Re: New heap spray vulnerability- does NoScript protect?

Posted: Thu Jul 16, 2009 1:57 am
by zombiez
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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Thu Jul 16, 2009 4:29 am
by Alan Baxter
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.

Re: New heap spray vulnerability- does NoScript protect?

Posted: Thu Jul 16, 2009 7:00 am
by Grumpy Old Lady
Content deleted.
Off topic.