Google Chrome Blink Serializer::doSerialize Bad Cast

`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  
`