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

[Ryosuke Niwa]

On Wed, Nov 14, 2012 at 11:37 PM, Chris Evans <cevans at chromium.org> wrote:

> On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
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.
>

Right. That kind of trade off makes sense.

But there’s also a danger of making our codebase too complex. As you’re
well aware, increasing code complexity will lead to more bugs including but
not limited to security bugs. I’ve been seen many new and even some
experienced contributors introducing memory management bugs because they’re
not used to either RefCounted objects or RenderArena allocated objects
because many people tend to work on either rendering code or DOM code but
not both.

If we’re deploying RenderArea for DOM nodes, I’d like to make sure we have
a solid API that’s extremely hard to misuse (in addition to making sure
adopting a node from one document to another doesn’t result in pathological
performance, etc…).

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

Are there other exploits we can get data from? Getting statistics from one
exploit results in a strong sampling bias so ideally we can assess whether
slab memory allocation is a good defense against other types of exploits.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121115/19a0df94/attachment.html>