Google Chrome Blink Serializer::doSerialize Bad Cast
Posted on 14 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 ninth entry in that series, and the first to not target a Microsoft browser. The below information is available in more detail on my blog at http://blog.skylined.nl/20161111001.html. Follow me on http://twitter.com/berendjanwever for daily browser bugs. Google Chrome blink Serializer::doSerialize bad cast ==================================================== (This fix and CVE number for this issue are not known) Synopsis -------- When serializing JavaScript objects for sending to another window using the `postMessage` method, the code in blink does not handle `Symbol` objects correctly and attempts to serialize this kind of object as a regular object, which results in a bad cast. An attacker that can trigger this issue may be able to execute arbitrary code. Known affected versions, attack vectors and mitigations ----------------------- * Chrome 38 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. Repro ----- <script> postMessage(Symbol()); </script> Description ----------- The repro causes a call to `blink::V8Window::postMessageMethodCustom`. This method creates a `Serializer` object for the "script value" of the symbol. In ``blink::`anonymous namespace'::Serializer::doSerialize`` the code attempts to determine the type of object being serialized and runs specific code to to serialize each type. This code does not distinguish between a `Symbol` and a regular object, and therefor runs code designed to handle the later to serialize the former. This results in a bad cast to a `v8::Object`. Exploit ------- The exploitability of a bad cast depends on many things, including what properties and methods the real object type and the object type it was cast to have, how much control an attacker has over the values of properties of the object, how the code proceeds to use the badly cast object, compiler optimizations, heap management, etc... Without further investigation it is impossible to say what an attacker could gain from exploiting this vulnerability. In this specific case, I did not have time to investigate exploitability on Google Chrome releases, so I cannot proof this is actually exploitable. Time-line --------- * October 2014: This vulnerability was found through fuzzing. * November 2014: This vulnerability was submitted to ZDI, iDefense and EIP. * December 2014: This issue appears to have been fixed and no longer reproduces. * December 2014: ZDI, iDefense and EIP all either reject the submission or fail to respond. * November 2016: Details of this issue are released. Cheers, SkyLined
