Last Friday, Polish researcher Michal Zalewski reported discovering an interesting little JavaScript trick that keeps a user stuck on a Web page even though he's trying to navigate somewhere else. His discovery involves the simple use of a JavaScript event to make it appear as though a browser is displaying any particular URL, when it's not.

When the exploit works, the onunload() event triggers the execution of JavaScript code the moment the user exits a Web page - which is how this JavaScript event is designed to work. But from there, the exploit would write information to the Web page without changing the contents of the address bar, potentially enabling a phisher to drop genuine-looking contents into a page to fool the user into thinking he's on a legitimate site.

Of course, the code itself would need to be attached to a page whose authenticity can't be questioned even though the event code hasn't been run yet. That's a tricky maneuver unless the HTML framework is being run by an e-mail client whose JavaScript interpreter is enabled.

In BetaNews tests of Zalewski's test page in IE7 on multiple Windows machines, including two XP-based systems and one Vista-based Virtual PC-driven environment, the test page failed to spoof a Web site effectively when the user attempts to exit the page by clicking on a link in IE7's Links toolbar or Favorites list. While the user is still stuck on the test page, the address bar continues to read the test page's address.

However, when an address is typed manually into the IE7 address bar, the user remains stuck on the Web page while the address bar continues to read what the user typed. If the user tries clicking Links or Favorites again, the page remains stuck, and the address bar continues to show what the user typed. Apparently, when IE7 allows JavaScript to process the onunload() event, it does not change the contents of the address bar - it continues to show whatever it did before.

That's not BetaNews! No, it's Michal Zalewski's trap, which appears to have effectively snarled Internet Explorer 7 in Windows Vista.

Conceivably, rather than keeping the user stuck on the test page, embedded code in a working exploit could direct the user to several false locations under the auspices of a legitimate site. But to cajole a user into believing the legitimacy of a document that directs him to type an address directly into the address bar rather than click a link is a tall order, which is probably why security firms such as Secunia are rating the vulnerability level of this bug as "less critical."

BetaNews tests of Firefox version 2.0.0.2 (the recently patched edition) in both Windows XP and Vista showed its behavior somewhat different - perhaps a little awkward, but still preventing exploitability. When running the same, unmodified JavaScript code that traps the IE7 user, instead of displaying the content of the test page, Firefox clears the page and leaves it blank. Meanwhile, its address bar reads the legitimate address of the site the user chooses, whether he types it into the address bar manually or clicks on his Links toolbar or Bookmarks pane.

Sometimes the Firefox browser window does remain stuck on the blank page and sometimes it does not. Exactly why this behavior only happens occasionally has not yet been determined.

So while the trick can't be used to spoof an address for a Firefox user, it could conceivably be used as a nuisance ploy - a dull one, but a nuisance nonetheless. Yesterday, Mozilla acknowledged the event handler bug, stating it had already been fixed in version 2.0.0.2, posted earlier this week.

Our research turned up instances of security researchers having discovered essentially the same problem with the onunload() event in Firefox as far back as July 2004, in Opera as far back as May 2004, and in Internet Explorer as far back as July 2004.

In BetaNews tests, additions and modifications to the JavaScript code that traps the IE7 browser user on the same page - for instance, trying to make it open another window - cause Firefox to stop execution of the code altogether, returning the browser to its normal behavior. In that instance, Mozilla's claimed fix appears to be effective.

There's nothing in the JavaScript code itself that makes IE7 and Firefox change its behavior in order to leave the address bar unchanged or leave the contents of the page blank. Also, it's very important to note here that JavaScript code running in IE7, even when triggered by the onunload() event, continues to run under the same restrictions as all other JavaScript code. So if JavaScript has no access to the file system normally, nothing triggered by this little trick will give it access automatically. Third-party firewalls continue to disable JavaScript code from manipulating cookies, by forcing the .cookie property to be changed to the .ignore property, as ZoneAlarm continued to do in BetaNews tests.

With more time, we may study the possibility that third-party popup blockers exacerbate the problem for Firefox, and may be responsible for the "blank page" occasions where Zalewski's trap does not appear 100% fixed.

Thus it would be inaccurate to state that this trick gives malicious users open access to remote users' data, as many blogs reported this afternoon, although the trick can be used to effectively mask JavaScript code from being run in an obviously detectable fashion by the user.