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 [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
