Microsoft Internet Explorer (IE) allows script from a dialog frame in one domain to execute in a different domain, including the Local Machine Zone. The script could read certain local files and data (i.e. cookies) from other web sites. In the presence of other vulnerabilities (VU#626395, VU#25249), the script could execute arbitrary commands.
Microsoft Internet Explorer provides two methods (showModalDialog and showModelessDialog) that can be used to display dialog box frames. The methods must specify a URI to use as the source of the dialog frame and they may take optional arguments, including script. These arguments can be accessed from the dialog frames using the dialogArguments property. Script passed as an argument to a dialog frame is subject to the security restrictions of the DHTML Object Model: script executing in one frame cannot access data in a frame from a different domain. In addition, script cannot access data using a different protocol. For example, script in a frame on cert.org cannot access data in a frame from example.com, and an http:// frame cannot access data using file:// or https://. The dialog methods may specify source URIs in a different domain than the parent frame, however the security restrictions should prevent script in one frame from accessing data in the other.
From MS03-004: "Internet Explorer evaluates security when one web page requests access to resources in another security zone. There is a flaw in the way Internet Explorer checks the originating domain when script runs in a dialog box." Internet Explorer does not correctly enforce cross-domain security when the source of a dialog frame is set using an IFRAME element (or object). In publicly available examples, one file on a web site creates a scripting object and calls a dialog method with two arguments: the source of the dialog frame (a second file on the same web site as the parent) and a reference to the scripting object. The second file instantiates an IFRAME using a local file resource (res://shdoclc.dll/privacypolicy.dlg, see VU#711843). The local resource fulfills a necessary precondition of the attack - it uses dialogArguments to access the script without adequate validation. Script that is passed as an argument to a dialog frame can be accessed from a different domain/protocol as specified in the IFRAME element of the dialog frame's source URL. As a result, the script can read data from the target domain.
Internet Explorer, Outlook, Outlook Express, MSN Messenger, Eudora, Lotus Notes, Adobe PhotoDeluxe, AOL, and any other software that hosts the WebBrowser ActiveX control could be affected by this vulnerability.
An attacker who is able to convince a user to access a specially crafted HTML document, such as an Internet web page or HTML email message, could execute arbitrary script in a different domain. When combined with cross-site scripting vulnerabilities in local HTML resources [VU#711843], the script could execute with privileges of the user in the security context of the Local Machine Zone. The script could read certain types of local files in known locations. In conjunction with other vulnerabilities (VU#626395, VU#25249), the script could execute arbitrary commands on the user's system.
Restrict HTML Help commands
Restrict the execution of the Shortcut and WinHelp HTML Help commands to specified folders, or disable the commands entirely. As in the previous recommendation, this technique will protect against arbitrary command execution via HTML Help. Details are available in Microsoft Knowledge Base Article 810687.
Several variations of this vulnerability were publicly reported by Thor Larholm, GreyMagic Software, and Liu Die Yu.
This document was written by Art Manion and Shawn Van Ittersum.
|Date First Published:||2003-04-25|
|Date Last Updated:||2007-06-05 14:01 UTC|