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

[Chris Evans]

On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Wed, Nov 14, 2012 at 10:14 PM, Cris Neckar <cdn at chromium.org> wrote:
>
>> On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>>> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth <abarth at webkit.org> wrote:
>>>
>>>> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" <rniwa at webkit.org> wrote:
>>>> >
>>>> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn <esprehn at chromium.org>
>>>> wrote:
>>>> >>
>>>> >> 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.
>>>> >
>>>> >
>>>> > I don’t think allocating all JS objects in an arena is good enough
>>>> because attackers can inject nearly arbitrary sequence of bytes into DOM
>>>> objects (e.g. text node).
>>>>
>>>> The text for a text node is stored in a String, not in the Node object
>>>> itself.
>>>>
>>> Yeah, I guess text node was not a good example. Now that I think about
>>> it, we can probably get most of security benefits of using RenderArena for
>>> DOM if we can allocate all strings & js objects from arena.
>>>
>>
>>>
>> You still have every other object type available to find useful
>> overlapping attributes. At best taking away JS objects is an annoyance and
>> will probably never make something impossible to exploit. On the other hand
>> DOMobjects in their own size class you would likely have many situations
>> where exploitation is actually not possible. I would much prefer that we
>> find a way to accomplish this with specific dangerous types rather than
>> just take away objects that make exploitation trivial.
>>
>
> Fair enough.
>
> On somewhat related question, how would you define "DOM objects"? There
> are many ref counted objects in WebCore that may not necessarily be exposed
> to the Web directly yet contain (derivatives of) page contents. Should we
> slab-allocate all such objects? Or are you specifically concerned about
> anything inherited from WebCore::Node / TreeShared?
>

I have a demo locally that is anything descended from WebCore::Node. I just
got a conflict from a sync but I'll send you the demo patch (as you asked
for earlier) once it's resolved.


> In other words, why are you interested in using the proposed allocation
> mechanism for only DOM nodes/objects instead of everything in
> WebCore/WebKit?
>

The challenge is to add partitioning without going too crazy on number of
partitions, whilst maximizing benefit (i.e minimizing the options the
attacker has.)

If we stuff every virtual class in WebCore/WebKit together, the attacker
has just tons of options for overlap of freed object and attacker-chosen
object. The situation is complicated by the presence of multiple vtables in
some classes.

To come up with the suggestion of partitioning off the Node hierarchy, I
actually did a "blind" analysis against the Pinkie Pie exploit. i.e. I
picked the best defense idea we had without fully dissecting the exploit
and then ran an analysis of how the defense would have impacted the
exploitability. With the defense in place, the attacker's options for this
particular case turned out to be severely limited and I couldn't find a
good place to start. I even managed to locate and chat to Pinkie Pie who
described the proposed defense as "quite useful".

I think I've realized an irony with RenderArena. I see now that it's a
semi-despised relic of the past. The irony is that the behavior it has is
very very similar to what you might spec out to provide a segregated, fast,
secure allocator.


Cheers
Chris


> - R. Niwa
>
>
> _______________________________________________
> 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/ef8961a6/attachment-0001.html>