<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa <span dir="ltr">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Nov 14, 2012 at 10:14 PM, Cris Neckar <span dir="ltr">&lt;<a href="mailto:cdn@chromium.org" target="_blank">cdn@chromium.org</a>&gt;</span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><span style="font-size:10pt">On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa </span><span dir="ltr" style="font-size:10pt">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</span><span style="font-size:10pt"> wrote:</span><br>


<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div>On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth <span dir="ltr">&lt;<a href="mailto:abarth@webkit.org" target="_blank">abarth@webkit.org</a>&gt;</span> wrote:<br>



</div></div><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div><p dir="ltr"><span style="font-size:10pt">On Nov 14, 2012 8:59 PM, &quot;Ryosuke Niwa&quot; &lt;</span><a href="mailto:rniwa@webkit.org" style="font-size:10pt" target="_blank">rniwa@webkit.org</a><span style="font-size:10pt">&gt; wrote:</span><br>



&gt;<br>
&gt; On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn &lt;<a href="mailto:esprehn@chromium.org" target="_blank">esprehn@chromium.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 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.<br>
&gt;&gt;<br>
&gt;&gt; Is there a reason we can&#39;t just do that? It&#39;s much less intrusive to allocate ArrayBuffer in an arena than to allocate all DOM objects in one.<br>
&gt;<br>
&gt;<br>
&gt; 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).</p>
</div></div><p dir="ltr">The text for a text node is stored in a String, not in the Node object itself.</p></blockquote></div></div><div>Yeah, I guess text node was not a good example. Now that I think about it, we can probably get most of security benefits of using RenderArena for DOM if we can allocate all strings &amp; js objects from arena.<span style="font-family:arial;font-size:small"> </span></div>


</div></div></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">


<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_quote"><div><span style="font-family:arial;font-size:small"> </span></div>


</div></div></div></blockquote></div></div></blockquote></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">


<div>You still have every other object type available to find useful overlapping attributes. At best taking away JS objects is an annoyance and will probably never make something impossible to exploit. On the other hand DOMobjects in their own size class you would likely have many situations where exploitation is actually not possible. I would much prefer that we find a way to accomplish this with specific dangerous types rather than just take away objects that make exploitation trivial.</div>



</div>
</blockquote></div><div><br></div><div>Fair enough.</div><div><br></div><div>On somewhat related question, how would you define &quot;DOM objects&quot;? There are many ref counted objects in WebCore that may not necessarily be exposed to the Web directly yet contain (derivatives of) page contents. Should we slab-allocate all such objects? Or are you specifically concerned about anything inherited from WebCore::Node / TreeShared?</div>
</blockquote><div><br></div><div>I have a demo locally that is anything descended from WebCore::Node. I just got a conflict from a sync but I&#39;ll send you the demo patch (as you asked for earlier) once it&#39;s resolved.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>In other words, why are you interested in using the proposed allocation mechanism for only DOM nodes/objects instead of everything in WebCore/WebKit?</div></blockquote><div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>To come up with the suggestion of partitioning off the Node hierarchy, I actually did a &quot;blind&quot; 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&#39;s options for this particular case turned out to be severely limited and I couldn&#39;t find a good place to start. I even managed to locate and chat to Pinkie Pie who described the proposed defense as &quot;quite useful&quot;.</div>
<div><br></div><div>I think I&#39;ve realized an irony with RenderArena. I see now that it&#39;s a semi-despised relic of the past. The irony is that the behavior it has is very very similar to what you might spec out to provide a segregated, fast, secure allocator.</div>
<div><br></div><div><br></div><div>Cheers</div><div>Chris</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>- R. Niwa</div><div><br>
</div>

<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
<br></blockquote></div><br></div>