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

[Maciej Stachowiak]

I had a few more thoughts on this email besides the fragmentation aspect.

On Nov 15, 2012, at 12:22 AM, Chris Evans <cevans at chromium.org> wrote:

> 
> It still seems to me like the key difference is vtable vs no vtable,
> 
> It's an important difference, but if we partitioned in to two based on that difference alone, we'd have the following issues:
> 
> 1) Classes with multiple vtables would spoil our day. The sheer number of classes in the "vtable" partition would practically ensure that an attacker could overlap data of their choosing on top of a secondary vtable.
> Overlap of attacker data onto a secondary vtable is also a concern with the DOM partition approach, but the chances of it being possible are much much lower. In the Pinkie Pie exploit case, the DOM arena solution made it impossible.

Are you thinking about classes with multiple inheritence? A couple of thoughts on this:

a) I think the majority of uses of multiple inheritence from classes with virtual methods (thereby leading to multiple vtables) is in subclasses of Node, e.g. in SVG. I don't see how this is much more a problem for broader-scope segregated allocation.

b) This could be addressed by allocating classes with multiple vtables separately from ones with single vtables, if the cost is worth it. That seems to address the issue more directly than making Node subclasses the cutoff.

Your comments on this make me worry that this mitigation might be overly tailored to the one specific exploit.

> 
> 2) The Pinkie Pie exploit wasn't exclusively about the vtable.
> Before you can abuse an overlap with a freed vtable pointer, you need to defeat ASLR. This was partly achieved by overlapping the pointer and size of a freed WTF::Vector member with arbitrary data. (This is highly dangerous for DOM objects as it can lead to a direct arbitrary memory read or write primitive from Javascript!) Again, the sheer number of classes in a "vtable" partition would make a collision profitable to the attacker a statistical likelihood. Again, with a strict DOM arena, possibilities are really shut down. Back to the Pinkie Pie case, there wasn't any immediately useful overlap in either the 32-bit or 64-bit memory layout.

Is defeating ASLR via this type of information disclosure useful in ways other than following up with an attack on a vtable? It seems like a lot of Node subclasses


Another thought is that the CSSOM is likely to be pretty vulnerable to these kinds of attacks too. So a DOM-specific solution may be too narrow, but at the same time, adding more and more different arenas is likely to cause bad fragmentation in pathological cases. This is why I think doing the segregation at a coarser granularity is a promosing approach.

Cheers,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121115/8d007d2f/attachment.html>