On Nov 15, 2012, at 12:22 AM, Chris Evans <[email protected]> wrote:
> On Wed, Nov 14, 2012 at 11:32 PM, Maciej Stachowiak <[email protected]> wrote: > > On Nov 14, 2012, at 11:09 PM, Chris Evans <[email protected]> wrote: > >> On Wed, Nov 14, 2012 at 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). >> >> 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. >> >> The most lethal use-after-frees, though, are DOM objects. A freed DOM object >> is often wired directly into Javascript and the attacker can prod all sorts >> of methods and properties on the freed object in order to cause a chosen set >> of accesses (corresponding to reads, writes and vtable usages under the >> covers) in a chosen order. >> >> 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, > > It's an important difference, but if we partitioned in to two based on that > difference alone, we'd have the following issues: > > 1) Classes with multiple vtables would spoil our day. The sheer number of > classes in the "vtable" partition would practically ensure that an attacker > could overlap data of their choosing on top of a secondary vtable. > Overlap of attacker data onto a secondary vtable is also a concern with the > DOM partition approach, but the chances of it being possible are much much > lower. In the Pinkie Pie exploit case, the DOM arena solution made it > impossible. > > 2) The Pinkie Pie exploit wasn't exclusively about the vtable. > Before you can abuse an overlap with a freed vtable pointer, you need to > defeat ASLR. This was partly achieved by overlapping the pointer and size of > a freed WTF::Vector member with arbitrary data. (This is highly dangerous for > DOM objects as it can lead to a direct arbitrary memory read or write > primitive from Javascript!) Again, the sheer number of classes in a "vtable" > partition would make a collision profitable to the attacker a statistical > likelihood. Again, with a strict DOM arena, possibilities are really shut > down. Back to the Pinkie Pie case, there wasn't any immediately useful > overlap in either the 32-bit or 64-bit memory layout. I would probably need to know more about it to comment intelligently. Maybe we could discuss offline or on the security list. > > 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. > > My read on the Arena is that it's fragmentation resistant (i.e. it will not > repurpose a larger free chunk to satisfy a smaller allocation.) However, > memory usage at any given time is defined by peak usage since it cannot > release pages back to the system without ruining its security guarantee. I'm talking about external fragmentation, not internal fragmentation. RenderArena is not resistant to it in any way. > Interestingly, it can't be super bad: we already bite this bullet for > RenderArena as used by RenderObjects. The RenderArena lifetime is the same as > the document / DOM and I was surprised to recently be told that we don't > throw away the RenderArena on a full layout. As mentioned previously, RenderObjects have some key different properties - they are guaranteed not to outlive the Document (or more specifically Document::detach) and they cannot be transferred from one render tree to another. So you know the whole arena can be discarded at a deterministic time. But that doesn't work for DOM nodes. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
