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

[Chris Evans]

On Thu, Nov 15, 2012 at 3:05 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

One reason to make Node the cutoff is that UAF of DOM objects is often more
dangerous because of the rich JS API the attacker can play with to take the
effect of the memory corruption in so many different ways. So the
non-vtable aspects of the exploitation get defended a little better due to
fewer attacker opportunities.

That said, I like the elegance of your single vtable suggestion. Let me
think about it.



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

It's a fair comment; and I did see your request for other examples in a
previous mail. Actual UAF exploits are hard to come by because many people
who write them are not incentivized to ever make them public. And the great
example I do have cost $60k ;-)

I'll work on getting more. Or, send me a bug which leaves a JS handle
pointing to a freed underlying DOM node and I could see about weaponizing
it.

There are bunch of historical examples such as
https://code.google.com/p/chromium/issues/detail?id=118273 which show
attackers are going after freed DOM node pointers, though. We only have the
bug and not an 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?
>

Yeah. Once you have a valid address, you can use that (e.g. set the
appropriate ArrayBuffer bytes at the right index) to be the basis for e.g.
a WTF::Vector. And set the length to 0xffffffff. Now, assuming there's a JS
API to make queries that are backed by the Vector, you get to read and
possibly write arbitrary memory.

If you can read arbitrary memory, you have a UXSS-class of vulnerability in
most setups.

If you can read or write arbitrary memory, you can target vtables, function
pointers, stacks... bad news at this stage.

The DOM arena approach does lead to less liklihood of being able to cause
useful overlap to do any of the above steps. If you like, you could imagine
the probability of useful attack for each step as being some function of
the number of different classes in the same partition. The vision behind
the DOM arena is to take the most dangerous UAFs and put them in a small
partition.


Cheers
Chris

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/1c8bb784/attachment.html>