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

[Elliott Sprehn]

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.

- E


On Wed, Nov 14, 2012 at 11:16 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> Following up on a bugzilla discussion:
>
> > It is indeed significant that only a small number of classes are
> allocated within RenderArena. For example, when there's a RenderObject
> which has been freed but is still in use, it's not possible for the
> attacker to allocate (e.g.) a raw ArrayBuffer contents on top of the freed
> slot. So the attacker cannot place arbitrary bytes on top of where the
> vtable pointer is expected to be. We've made sure that the first
> sizeof(void*) bytes either point to a valid vtable pointer, or are a
> poisoned freelist pointer, or are an invalid pointer in the case that one
> of the (few) non-virtual classes is overlaid.
> >
> > It's essentially about limiting the attacker's possibilities when the
> inevitable rendering use-after-frees occur. There are some other non vtable
> related possibilities that get limited too.
>
> Interesting! How much value would be derived from allocating all classes
> with a virtual method in a separate heap from classes with no vtable and
> raw data buffers? And how much is specifically due to a more limited range
> of classes that may be present in the RenderArena? If classes with vtables
> getting overwritten by arbitrary data are the top fear, then there is
> probably a more modest solution than RenderArena. It could still cause
> additional memory fragmentation, but probably less so than RenderArenas.
>
> Regards,
> Maciej
>
> _______________________________________________
> 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/56f032a7/attachment.html>