Since November I have been releasing details on all vulnerabilities I found in web-browsers that I had not released before. I will try to continue to publish all my old vulnerabilities, including those not in web-browser, as long as I can find some time to do so. If you find this information useful, you can help me make more time available by donating bitcoin to 183yyxa9s1s1f7JBpPHPmzQ346y91Rx5DX. This is the twenty-sixth entry in the series. This information is available in more detail on my blog at http://blog.skylined.nl/20161206001.html. There you can find repros that triggered this issue in addition to a Proof-of-Concept exploit, as well as the information below. Today's release is interesting, in part because it is an odd vulnerability that I've not seen before or since: it's like a stack-based use-after-free. The time-line is also interesting in that ZDI first did not believe it to be exploitable and EIP thought it was a duplicate of a bug they had already reported to Microsoft. Both turned out to be wrong. Then I reported it to iDefense as well, who accidentally send the details over plain-text email, causing ZDI to reject my submission for fear of the bug leaking to the public. Luckily for me, iDefense did end up acquiring the bug. Follow me on http://twitter.com/berendjanwever for daily browser bugs. MSIE jscript9 JavaScriptStackWalker memory corruption ===================================================== (MS15-056, CVE-2015-1730) Synopsis -------- 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. Known affected software and attack vectors ------------------------------------------ * Microsoft Internet Explorer 9 An attacker would need to get a target user to open a specially crafted web-page. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path. Description ----------- MSIE attempts to handle stack exhaustion caused by excessive recursion in Javascript gracefully by generating a JavaScript exception. While generating the exception, information about the call stack is gathered using the JavascriptStackWalker class. It appears that the code that does this initializes a pointer variable on the stack the first time it is run, but re-uses it if it gets called a second time. Unfortunately, the information the pointer points to is also stored on the stack, but is removed from the stack after the first exception is handled. Careful manipulation of the stack during both exceptions allow an attacker to control the data the pointer points to during the second exception. Exploit ------- 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. Further details of how to exploit this issue can be found in my blog at http://blog.skylined.nl/20161206001.html Time-line --------- * 13 October 2012: This vulnerability was found through fuzzing. * 29 October 2012: This vulnerability was submitted to EIP. * 18 November 2012: This vulnerability was submitted to ZDI. * 27 November 2012: EIP declines to acquire this vulnerability because they believe it to be a copy of another vulnerability they already acquired. * 7 December 2012: ZDI declines to acquire this vulnerability because they believe it not to be exploitable. 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. * April 2014: I start working on this case again, and eventually develop a working Proof-of-Concept exploit. * 6 November 2014: ZDI was informed of the new analysis and reopens the case. * 15 November 2014: This vulnerability was submitted to iDefense. * 16 November 2014: iDefense responds to my report email in plain text, potentially exposing the full vulnerability details to world+dog. * 17 November 2014: ZDI declines to acquire this vulnerability after being informed of the potential information leak. * 11 December 2012: This vulnerability was acquired by iDefense. 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. * 9 June 2015: Microsoft addresses this vulnerability in MS15-056. * 6 December 2016: Details of this vulnerability are released. Cheers, SkyLined
Attachment:
0x2557C5AA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
