bitlance winter has reported a vulnerability in Internet Explorer (IE), allowing malicious people to bypass security zones or conduct phishing attacks.

The vulnerability is caused due to an error within the handling of URLs, which may cause IE to view a web site in context of another less secure security zone than intended.

Example:
http://[trusted_site]%2F%20%20%20.[malicious_site]/

Successful exploitation may allow a web page to be displayed in context of another domain e.g. in the "Trusted sites" or "Local intranet" security zones. However, a malicious web site's domain has to support wildcard DNS and accept invalid values in the "Host:" header.

The issue can also be exploited to potentially trick users into supplying sensitive information to a malicious web site, because information displayed in the address bar can be constructed in a certain way. This may lead users to believe that they're visiting another web site than the displayed web site.

The vulnerability has been confirmed on a fully patched Windows XP system with IE 6.0. Other versions may also be affected.

NOTE: The vulnerability may present a greater risk on systems, where predictable domains are in the "Trusted sites" zone. This can also be combined with other unfixed vulnerabilities to bypass mitigating steps, where Active Scripting has been disabled for all zones but "Trusted sites".

UPDATE: A sample exploit has been posted which can place arbitrary content in the Startup folder and possibly other locations using the inherently insecure Microsoft Windows "shell:" URI handler functionality. The exploit utilises the fact that Internet Explorer believes that it is operating in the "Trusted sites" zones to access the "shell:" URI handler. This exploit has been confirmed to work on a fully patched system running Internet Explorer 6 and Windows XP SP1.

The exploit requires the user to drag'n'drop an image to a different place on the webpage. However, it may be possible to trigger a drag'n'drop event by a single click using issue 2 in:
SA12048

Solution
The vulnerability has been fixed silently in some cumulative security update.

Provided and/or discovered by
bitlance winter
Sample exploit by http-equiv

Changelog
Further details available to Secunia VIM customers

Deep Links
Links available to Secunia VIM customers