On Nov 14, 2012, at 9:59 PM, Adam Barth <[email protected]> wrote: > > On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" <[email protected]> wrote: > > > > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn <[email protected]> > > 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
