[webkit-dev] RenderArena: Teaching an old dog new tricks

[Chris Evans]

On Wed, Nov 14, 2012 at 8:59 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn <esprehn at chromium.org>wrote:
>
>> I was present for one of the discussions about the exploit and how an
>> arena like allocator could have helped at Google. One proposed solution was
>> to allocate all the JS typed buffers in an arena.
>>
>> Is there a reason we can't just do that? It's much less intrusive to
>> allocate ArrayBuffer in an arena than to allocate all DOM objects in one.
>>
>
> I don’t think allocating all JS objects in an arena is good enough because
> attackers can inject nearly arbitrary sequence of bytes into DOM objects
> (e.g. text node).
>

Yeah, pretty much this. The worry is that it's very hard to be sure you've
identified all cases / classes where the attacker has reasonable control
over the size and exact content of the allocation. You have to start
looking at the buffers backing ArrayBuffers, the buffers backing
WTF::Vectors, the buffers backing the (multitude of) string classes, and
even then, you're left worrying about objects that simply have a bunch of
consecutive ints that the attacker can set as properties, etc. And even in
the unlikely event you catch everything in WebKit, you still have other
very attacker-controllable allocations going on in the same process such as
audio and video packets; canvas buffers; rendered image buffers; the list
goes on. I don't think it's a battle than can be won.

So we think the problem is best approached from another observation:

- Use-after-free of certain classes is either very lethal, or very common,
or both.

Use-after-free is pretty common for the RenderObject hierarchy and the Node
hierarchy. Inferno ran a quick script for use-after-free stats in automated
ClusterFuzz reports and it was approximately 332 Render and 134 Node. Due
to historical accident, we already have a protection for RenderObject.

The most lethal use-after-frees, though, are DOM objects. A freed DOM
object is often wired directly into Javascript and the attacker can prod
all sorts of methods and properties on the freed object in order to cause a
chosen set of accesses (corresponding to reads, writes and vtable usages
under the covers) in a chosen order.

I'm not comfortable sharing it verbatim on a public list, but happy to send
you a copy of the Pinkie Pie exploit if you're interested. It relies on a
lethal DOM use-after-free.

Because use-after-free in the Node hierarchy is both common and lethal, a
separate allocation area seems a profitable path forward.


Cheers
Chris


> - R. Niwa
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/1e387e9b/attachment.html>