Chrome Blink SpeechRecognitionController Use-After-Free
Posted on 23 November 2016
Throughout November, I plan to release details on vulnerabilities I found in web-browsers which I've not released before. This is the seventeenth entry in that series. Unfortunately I won't be able to publish everything within one month at the current rate, so I may continue to publish these through December and January. The below information is available in more detail on my blog at http://blog.skylined.nl/20161123001.html. There you can find a repro that triggered this issue, snippets from the vulnerable source and more details in addition to the information below. Follow me on http://twitter.com/berendjanwever for daily browser bugs. Chrome blink SpeechRecognitionController use-after-free ======================================================= (Chromium 455857, CVE-2015-1251) Synopsis -------- A specially crafted web-page can cause the blink rendering engine used by Google Chrome and Chromium to continue to use a speech recognition API object after the memory block that contained the object has been freed. An attacker can force the code to read a pointer from the freed memory and use this to call a function, allowing arbitrary code execution. Known affected software and attack vectors ------------------------------------------ + Google Chrome 39.0 An attacker would need to get a target user to open a specially crafted webpage. Disabling Javascript should prevent an attacker from triggering the vulnerable code path. Description ----------- Creating a `webkitSpeechRecognition` Javascript object in a popup window before closing the popup frees a C++ object used internally by the speech recognition API code but leaves a dangling pointer to the freed memory in another C++ object. When the `start()` Javascript method is called, this dangling pointer is used to try to read a function pointer from a virtual function table and call that function. An attacker has ample time to groom the heap between the free and re-use in order to control the function pointer used by the code, allowing arbitrary code execution. Exploit ------- An attacker looking to exploit this issue is going to want to try and control the contents of the freed memory, before getting the code to use the dangling pointer to call a virtual function. Doing so would allow an attacker to execute arbitrary code. This is made possible because steps 5 and 6 can both be triggered at a time of the attackers choosing, giving the attacker the ability to free the memory in step 5 whenever this is convenient and attempt to reallocate and fill it with any data before executing step 6. This should allow an attacker to create a fake `vftable` pointer and gain arbitrary code execution. In order to develop a working exploit, existing mitigations will need to be bypassed, most significantly ASLR and DEP. As this vulnerability by itself does not appear to allow bypassing these mitigations, I did not develop a working exploit for it. Time-line --------- * November 2014: This vulnerability was found through fuzzing. * December 2014: This vulnerability was submitted to ZDI and iDefense. * January 2015: This vulnerability was acquired by ZDI. * February 2015: This vulnerability was fixed in revision 190993. * May 2015: This vulnerability was addressed by Google in Chrome 43.0.2357.65. * November 2016: Details of this issue are released. Cheers, SkyLined Repro.html <html> <head> <script> oAWindow = window.open(); oAWebkitASpeechARecognition = new oAWindow.webkitASpeechARecognition(); oAWindow.close(); setAInterval(function(){ if (oAWindow.closed) { oAWebkitASpeechARecognition.start(); } }, 10); </script> </head> </html>
