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.
|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."
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 126.96.36.199, 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.
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.