[Webkit-unassigned] [Bug 174924] Strings need to be in some kind of gigacage

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=174924

--- Comment #2 from Filip Pizlo <fpizlo at apple.com> ---
Actually, we need to be careful about which cage we put strings into, since that means allocating StringImpl's along with StringImpl::m_data in that cage.  So, it would only make sense if StringImpl::m_data never pointed out of the cage.  Otherwise, we cannot cage m_data, so primitive writes intended for other objects in the primitive cage could be used to redirect m_data.  We cannot cage m_data without disabling the no-copy optimizations in things like ASCIILiteral.

One way to get some of the benefit of caging is to allocate StringImpls and their backing stores in a string cage whenever possible, but don't cage accesses.  This would mean that you could use string reads to explore the heap, but only after you construct a bogus string pointer.

Alternatively, we could eat the perf cost of disabling the no-copy optimization in ASCIILiteral and introduce some lazy allocation in StaticStringImpl.  In that world, we can put StringImpl and its backing stores in either their own cage or the primitive cage.  The m_data pointer would stop being a real pointer, since it would be caged.  So, it could be scrambled.

It seems like the most secure situation would be one where we eat the perf cost and also give strings their own cage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170813/c66e9308/attachment.html>