[webkit-dev] RenderArena: Teaching an old dog new tricks
mjs at apple.com
Wed Nov 14 23:32:44 PST 2012
On Nov 14, 2012, at 11:09 PM, Chris Evans <cevans at chromium.org> wrote:
> On Wed, Nov 14, 2012 at 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).
> Yeah, pretty much this. The worry is that it's very hard to be sure you've identified all cases / classes where the attacker has reasonable control over the size and exact content of the allocation. You have to start looking at the buffers backing ArrayBuffers, the buffers backing WTF::Vectors, the buffers backing the (multitude of) string classes, and even then, you're left worrying about objects that simply have a bunch of consecutive ints that the attacker can set as properties, etc. And even in the unlikely event you catch everything in WebKit, you still have other very attacker-controllable allocations going on in the same process such as audio and video packets; canvas buffers; rendered image buffers; the list goes on. I don't think it's a battle than can be won.
> So we think the problem is best approached from another observation:
> - Use-after-free of certain classes is either very lethal, or very common, or both.
> Use-after-free is pretty common for the RenderObject hierarchy and the Node hierarchy. Inferno ran a quick script for use-after-free stats in automated ClusterFuzz reports and it was approximately 332 Render and 134 Node. Due to historical accident, we already have a protection for RenderObject.
> I'm not comfortable sharing it verbatim on a public list, but happy to send you a copy of the Pinkie Pie exploit if you're interested. It relies on a lethal DOM use-after-free.
> Because use-after-free in the Node hierarchy is both common and lethal, a separate allocation area seems a profitable path forward.
It still seems to me like the key difference is vtable vs no vtable, rather than DOM vs. not DOM. Also having a per-document arena for DOM nodes (as is done for render objects via RenderArena) seems irrelevant to the security goal and likely to cause bad memory fragmentation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev