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

[Maciej Stachowiak]

On 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).
> 
Just to be precise here, I imagine the thing you'd probably want to segregate is the "void* m_data" member of ArrayBufferContents.
> The text for a text node is stored in a String, not in the Node object itself
> 

Is the buffer for a String likely to be materially easier or harder to use for this than the buffer for an ArrayBuffer? It seems like "const UChar* m_data16" is likely to be nearly as dangerous (ok, so it's not mutable, this might make a difference).

I feel like, to the extent there is a material distinction being made here, it is between objects starting with a vtable pointer (which is trusted by the C++ runtime to point to code) vs. allocations of the same size class that don't start with a vtable and where memory in that initial word can be freely controlled (so you can make it point to a fake vtable which points to your attack code).

Of course, I am talking without having actually seen any detail on the analysis folks are talking about, so I may be missing the point.

Cheers,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/4ce03272/attachment.html>