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