Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - onUnload() InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

onUnload()

Published: 2007-02-26
Last Updated: 2007-02-26 23:25:38 UTC
by Swa Frantzen (Version: 3)
0 comment(s)
What happens when an adept of the dark side of the force looks at the documentation on javascript's onUnload() function ?

Take a look for yourself and come back, we won't go anywhere:
So something that gets called no matter how the user tries to get away from a web page. Imagine what pages you might want to get away from ...

As the MSDN article says, adding a window.open() call in such a routine becomes a nightmare for the visitor as (s)he'll never manage to get away on his/her own. Pop-up blockers should -if all goes right- detect and prevent that one case. But it gets worse, how about "location = self.location;" ? Right, the visitor doesn't go away at all.

Is there anything new to this? Not as such, it's been known for years and was e.g. discussed in August of 2005 on full disclosure mailing lists.

One would assume open discussion of such a function where it's being labeled as potentially evil would cause security conscious developers to take note of such a dangerous function and severely limit it's possibilities, or better yet to get rid of it altogether.

Yet there seems to have been no such luck. Worse, there seems to have been renewed attention form those using the dark side as evidenced by these recent reactions:

MSIE 7: CVE-2007-1091 (mitre) or CVE-2007-1091 (nist)
"Microsoft Internet Explorer 7 allows remote attackers to prevent users from leaving a site, spoof the address bar, and conduct phishing and other attacks via onUnload Javascript handlers. "

We've henve updated the table tracking the known vulnerabilities in Microsoft products.
Firefox: US-CERT Vulnerability Note VU#393921
"Mozilla Firefox fails to properly handle JavaScript onUnload events. Specifically, Firefox may not correctly handle freed data structures modified in the onUnload event handler possibly leading to memory corruption. By convincing a user to view a specially crafted HTML document (e.g., a web page or an HTML email message or attachment), an attacker may be able to execute arbitrary code with the privileges of the user."
Firefox seems to have fixed it in versions 2.0.0.2 and 1.5.0.10
Personally I've a hard time to see how supporting onUnload() matches with statements such as:
"Put safety first.
Robust new Internet Explorer 7 architecture and improved security features help protect you against malicious software, and help to keep your personal data safe from fraudulent websites and online phishing scams." (taken from http://www.microsoft.com/windows/products/winfamily/ie/default.mspx )
Firefox has a "security is important" statement just as well.

Best course of action: disable scripting, but most of you can't or don't want to do that. The second best alternative might be to use extensions such as NoScript in Firefox that allows more selective control of who gets to do remote code execution in your browser. Yes that's what allowing java, VBscript and javascript basically is: allowing random websites to hand your browser code to execute ...

--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)
Diary Archives