This post explores the Type Confusion discovered by Cybellum’s automated vulnerability detection platform in Edge and Internet Explorer. It was reported to Microsoft on August 21st. Microsoft has confirmed the vulnerability.
Cybellum’s platform discovers numerous vulnerabilities on a weekly basis, as we train it by having it test popular software. The vulnerabilities it detects are disclosed to affected vendors.
Our vulnerability detection platform has discovered a type confusion vulnerability that affects both Microsoft Edge and Microsoft Internet Explorer. The vulnerability occurs in the browser’s layout rendering engine (EdgeHTML & MSHTML).
The vulnerability affects the latest version of both browsers.
The type confusion occurs in the function window.requestAnimationFrame, which expects to receive a single function pointer parameter. The vulnerability occurs because the function doesn’t properly validate the parameter, and may be called with a value that is not a function pointer (an integer value).
The supplied integer is treated as a pointer, going through a series of dereferences and a compare function, if all the requisites are satisfied the function will perform a last dereference and return that value to the caller.
Note that the first dereference is not the exact integer supplied to requestAnimationFrame, but rather ((INT_VALUE * 2) + 5). e.g. In order to dereference the value 0x41414141, we will call requestAnimationFrame with the integer 0x20A0A09E.
The returned value is dereferenced two more times, with the last dereference getting the actual function pointer value. This function pointer is checked against CFG protection (0x5f3c935f). If the test succeeds, the function pointer will be called, giving the attacker full control over EIP (0x5f3c9365).
The only prerequisite required for the vulnerability to be triggered, is making the function [email protected] return “true”.
This is required because the actual vulnerability happens in the function [email protected]
If we take a look at AreAnyListenersFastCheck, we can see the function returns true if:
– _Microsoft_IEEnableBits bit value 0x80000000 is set.
– At least one CDebugCallbackNotificationHandler has been registered.
Currently, the easiest and most reliable way to trigger the vulnerability is opening the developer tools (F12), which sets _Microsoft_IEEnableBits to 0xffffffff.
The developer tools don’t have to be open during the actual exploitation. Opening the developer tools sometime during the browser execution sets _Microsoft_IEEnableBits to 0xffffffff for the entire lifetime of the process.
This vulnerability has been discovered while the developer tools were turned off, so satisfying AreAnyListenersFastCheck is possible without opening the developer tools but requires further research.
In order to exploit this vulnerability we need to:
1. Successfully control a series of dereferences.
2. Successfully bypass\\satisfy the CFG protection check.
3. Once full control over EIP is achieved, continue with standard exploitation until code execution has been achieved.
Practical exploitation of this vulnerability isn’t trivial, and might require combining it with another vulnerability (e.g. an info leak). That said, this is a great starting point for a multi-browser (Edge\\IE) remote code execution exploit.
Proof of Concept
The easiest and most reliable steps to reproduce the vulnerability are:
1. Open Edge or IE.
2. Open the developer tools (F12).
3. Open the following html file:
The vulnerability affects both the x86\\x64 versions of Internet Explorer but only the x86 version of Edge. Exploiting the x64 of Edge might be possible, but requires further research.
To read more about the disclosure procedure in this case, please read this blog post.
Subscribe to get our vulnerability analysis posts, new blog content and very infrequent special announcements. We won’t spam you, and will never sell your data.
Did you find this interesting? Share it with others: