Escaping From Protected Mode Internet Explorer with BNO Namespace Squatting Attacks

Back in early 2011, I did some research into ways of escaping the Protected Mode Internet Explorer (PMIE) sandbox. Having had some time between jobs recently, I looked into writing an exploit for one of the bugs, a Low to Medium Integrity privilege escalation, which can also be used to escape the current Adobe Reader X sandbox.

I didn’t finish the exploit, but I think it’s still worth sharing because at the time I reported the issue¬†Microsoft decided not to issue a patch and the issue is still unfixed in the Windows 8 Consumer Preview. This is in part because they do not regard PMIE as implementing a security boundary, but their decision was potentially also influenced by the lack of any proof-of-concept code. Plus, I think the bug nicely demonstrates the practicality of “BNO Namespace Squatting” attacks.

“BNO Namespace Squatting” attacks are possible when two process running with different privileges share an object namespace and the higher privileged process creates an object (such as a shared section) with a predictable name, but doesn’t check that the object already exists. In this situation, the lower privileged process can specify arbitrary permissions on the created object.

In the exploit, a Low Integrity¬†CreateFileMapping() is used to create a shared section by the Low Integrity process (inside the sandbox) and the PMIE broker process running at Medium Integrity (outside the sandbox) calls CreateFileMapping() again for a shared section with the same name. The second call succeeds, though GetLastError() returns ERROR_ALREADY_EXISTS. An added complication is that the name of the shared section isn’t static, but contains the Process ID (PID) of the broker process which hasn’t been created yet. To avoid having to predict the PID of the broker process (although this is possible) a large number of malicious shared sections are created.

The shared sections relate to Loosely Coupled IE (LCIE) functionality and are of the form: “ie_lcie_sf2main_<PID>”. Where the PID is a lower-case hexadecimal number.

Once the malicious shared section is accessed by the PMIE broker, a function pointer is called, which is under the control of the Low Integrity process and therefore control of EIP is gained.¬†However, before the function pointer is called, the PMIE broker is terminating and the cause of this is currently unknown – thus why the exploit is unfinished. MSRC did originally confirm the bug as being exploitable, so I’m reasonably confident that I could finish the exploit given enough time.

 

The exploit code and related files can be found here, additional notes can be found in the source comments.

For more information, see: