A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Internet Explorer 9. A pointer set up to point to certain data on the stack can be used after that data has been removed from the stack. This results in a stack-based analog to a heap use-after-free vulnerability. The stack memory where the data was stored can be modified by an attacker before it is used, allowing remote code execution.
Microsoft Internet Explorer 9
URIError object and sets that object's
property to refer to the
URIError object, creating a circular reference. When
URIError object to a string,
MSIE attempts to convert the
name to a string, which
creates a recursive code loop that eventually causes a stack exhaustion.
This problem is not limited to the
URIError object: any recursive function
call can be used to trigger the issue, as shown in the exploit below.
As mentioned above, the vulnerable pointer points to valid stack memory during the first exception, but it is "popped" from the stack before the second. In order to exploit this vulnerability, the code executed during the first exception is going to point this pointer to a specific area of the stack, while the code executed during the second is going to allocate certain values in that same area before the pointer is re-used.
Control over the stack contents during a stack exhaustion can be achieved by making the recursive calls with many arguments, all of which are stored on the stack. This is similar to a heap-spray storing values on large sections of the heap in that it is not entirely deterministic, but the odds are very highly in favor of you setting a certain value at a certain address.
The exploit triggers the first exception by making recursive calls using a lot
of arguments. In each loop, a lot of stack space is needed to make the next
call. At some point there will not be enough stack space left to make another
call and an exception is thrown. If
N arguments are passed during each call,
N*4 bytes of stack are needed to store them. The number of bytes left on the
stack at the time of the exception varies from
0 to about
4*N and thus
averages to about
4*N/2. The vulnerable pointer gets initialized to point to
an address near the stack pointer at the time of the exception, at
(bottom of stack) + 4*N/2.
The exploit then triggers another stack exhaustion by making recursive calls
using many arguments, but significantly less than before. If
M arguments are
passed during each call this time, the number of bytes left on the stack
at the time of the exception averages to about
When the second exception happens, the vulnerable pointer points inside the stack that was "sprayed" with function arguments. This means we can control where it points to. The pointer is used as an object pointer to get a function address from a vftable, so by using the right value to spray the stack, we can gain full control over execution flow.
The below schematic shows the layout of the stack during the various stages of this exploit:| | |<--bottom of stack top of stack-->| | | | Stack layout at the moment the first exception is triggered: | | | | [--- CALL X ---][-- CALL X-1 --][-- CALL X-2 --][...........]| | | |<---------------> Stack space available is less than 4*N bytes | | | | ^^^ | | Vulnerable pointer gets initialized to point around here | | | | | | | | Stack layout at the moment the second exception is triggered: | | | | [CALL Y][CALL Y-1][CALL Y-2][CALL Y-3][CALL Y-3][........................]| | | |<--> Stack space available is less than 4*M bytes | | | | ^^^ | | Vulnerable pointer still points around here, most likely at | | one of the arguments pushed onto the stack in a call. | | |
In the Proof-of-Concept code provided below, the first exception is triggered
by recursively calling a function with 0x2000 arguments (
N = 0x2000). The
second exception is triggered by recursively calling a function with 0x200
M = 0x200). The values passed as arguments during the second stack
exhaustion are set to cause the vulnerable pointer to point to a fake vftable
on the heap. The heap is sprayed to create this fake vftable. A fake function
address is stored at 0x28000201 (
pTarget) that points to a dummy shellcode
consisting of int3's at 0x28000300 (
pShellcode). Once the vulnerability is
triggered, the vulnerable pointer is used to read the pointer to our shellcode
from our fake vftable and called, which will attempt to execute our shellcode.
During the initial report detailed above, I did not have a working exploit to prove exploitability. I also expected the bug to be fixed soon, seeing how EIP believed they already reported it to Microsoft. However, about two years later, I decided to look at the issue again and found it had not yet been fixed. Apparently it was not the same issue that EIP reported to Microsoft. So, I decided to try to have another look and developed a Proof-of-Concept exploit.
The accidentally potential disclosure of vulnerability details by iDefense was of course a bit of a disappointment. They reported that they have since updated their email system to automatically encrypt emails, which should prevent this from happening again.
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version. BugId report: jscript9.id: jscript9.
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version.id: jscript9.