Analysis on Internet Explorer's UXSS

04 February 2015

Recently a Universal Cross-Site Scripting(UXSS) vulnerability was disclosed on Full Disclosure mailing list. The unpatched 0day vulnerability discovered by David Leo can lead to a full bypass of the Same-Origin Policy(SOP) on the latest version of Internet Explorer. This article will briefly explain the technical details behind the vulnerability.

The Attack

The original Proof-of-Concept(PoC) can be boiled down into the following simplified one:

<iframe src="redirect.php"></iframe>
<iframe src="https://www.google.com/images/srpr/logo11w.png"></iframe>
<script>
    top[0].eval('_=top[1];alert();_.location="javascript:alert(document.domain)"');
</script>

The simplified PoC requires an iframe with a HTTP redirect to a resource on the target domain, and another iframe which also loads a resource on the target domain. What is worth noting is that the two resources do not necessarily need to be the same, nor their Content-Type matter. In summary:

  1. Browser renders the first iframe and issues a request to redirect.php.
  2. Browser renders the second iframe and issues a request to target resource.
  3. Browser executes the script which invokes eval on the WindowProxy object of the first frame and perform the following steps:
    1. Assign the WindowProxy object of the second frame to a variable.
    2. Popup an alert dialog box.
    3. The dialog box is closed by the user.
    4. Change the location via the variable assigned of the second frame and inject our payload.
  4. The injected payload is executed on the second frame on the target’s origin.

Under The Hood

Apparently, the key of the vulnerability appears to be the dialog box. Before diving into it, it is necessary to know that dialog boxes like alert, prompt, and confirm (or synchronized functions) will freeze browsers’ process due to JavaScript’s single-threaded nature. However, the concrete implementation slightly differs on different browsers. Let’s take a look on the timelines of each browser handling the PoC:

Firefox

When the dialog box pops up, Firefox will continue to handle network requests. After the target resource on frame 1 was redirected and finished loading, the original script execution will be terminated and the dialog box will be closed automatically at the same time (NS_ERROR_NOT_AVAILABLE: prompt aborted by user). Therefore, anything after the dialog box will never be executed.

Chrome

When the dialog box pops up, all network traffic in Chrome will be clogged up, until the dialog box is manually closed. After that, even the location change can be executed, there won’t be any danger since the origin of frame 1 remains the same (attacker’s) instead of target’s origin.

Internet Explorer

When the dialog box pops up, Internet Explorer will also continue to handle network requests. However, when the dialog box is manually closed after the target resource finished loading, the location change will be executed on behalf of the target resource (i.e. target’s origin).

The Root Cause

Before redirecting to target resource, script execution does not break SOP because redirect.php is still on the attacker’s origin. However, once the target resource finished loading on frame 1, Internet Explorer will update the origin data accordingly. As a result, the previous script execution will suddenly be treated as the same origin of the targets', and hence able to manipulate other WindowProxy object on the target’s origin. As a side note, the attack has to be done using two iframes because Internet Explorer will remove all the object references once navigation occurs. The suggested fix should be either terminate the script execution or remain the origin data when navigation occurs.

User Interaction

It seems that the attack requires user interaction (dialog box) which makes it less plausible. Actually it does not. Consider the following improved PoC:

<iframe src="redirect.php"></iframe>
<iframe src="https://www.google.com/images/srpr/logo11w.png"></iframe>
<script>
    top[0].eval('_=top[1];with(new XMLHttpRequest)open("get","sleep.php",false),send();_.location="javascript:alert(document.domain)"');
</script>

In essence, abusing dialog boxes is just one way to achieve thread blocking. We can issue a synchronous request with an artificial delay using XMLHttpRequest.

Affected Versions

It is confirmed that the vulnerability affects Internet Explorer 10 and 11 on Windows 7 and Windows 8.1.

Updated: This might be a regression bug of CVE-2014-0293.

Remedy

References

@filedescriptor