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

[Maciej Stachowiak]

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