Some Brief Notes on WebKit Heap Hardening

In the spirit of Chris Rohlf's blog posts, I decided to spend a week taking a time boxed poke at the modified allocator with a few key goals:

• How does the allocator work with the new changes?
• What allocations aren't protected by Gigacage? And can these easily be leveraged in exploits?
• Are any classes of bugs fully mitigated by the changes?

The original commit merging the changes in can be found here: https://github.com/WebKit/webkit/commit/197cd32c3b5527e8c2bbe3fcb7d78cc993dd8904 but there have been some patched since to protect additional items.

The memory allocator code itself can be found within: https://github.com/WebKit/webkit/tree/master/Source/bmalloc/bmalloc

Historically WebKit had a single heap with no isolation. This is very different to other browsers such as Internet Explorer which began separating DOM objects and other objects in June 2014 (as described on MWR Labs) and even Flash has had some form of separation for exploit prone objects since July 2015 (described by Google Project Zero here).

However with these recent changes WebKit has massively stepped up its game. WebKit now features four separate heaps, along with some further isolation features I'll outline in following sections. These types are outlined in the HeapKind enum found here and shown below.

The Primary heap is used for standard allocations made using fastMalloc, whether these allocations are made in WebKit or JSC they'll live in the same heap. 

Meanwhile the the JSValueGigacage is used for objects backed by 'butterflies', these data structures exist within JSC and are explained well in this Phrack article, with the key point shown here: 

The PrimitiveGigacage is currently being predominantly used for anything backed by native arrays, for example ArrayBufferViews and Wasm memory allocations.

Finally the fairly self explanatory named StringGigacage is being used for string object allocations, via the StringMalloc function. 

Currently there are only 4 separate heaps available but the current implementation supports up to 21, as can be seen within the ensureGigacage function which is called by WebKit on process creation.

This clearly shows that there are plans to expand this and create more Giacage based heaps in the future.

A Gigacage is a separate heap used to allocate objects that have been put within a specific class. One the key attack patterns WebKit is attempting to prevent here is for example finding a heap overflow within a JavaScript or DOM object and using this to modify the length field of a string or buffer object. The string or buffer can then be used for arbitrary memory read and/or write to any memory within the new range if the length field has been maxed out.

With these objects contained within a separate heap, it should not be possible to have them placed in memory used by targeted objects (stored in a different Gigacage or heap) in a Use After Free (UAF) exploit or precisely placed near targeted objects that are being used with Out Of Bounds (OOB) read/write bugs.

Memory must be explicitly allocated in a Gigacage using the bmalloc API, by default the HeapKind Primary will be used, leading to memory being allocated on the standard heap, however if a HeapKind enum value for a Gigacage is passed to any of the API functions the appropriate Gigacage will be used. Most uses of Gigacage abstract this out, for example the usage of jsValueMalloc or stringMalloc within the WTF sub project.

Each Gigacage is sized to be big enough that even if you have arbitrary out of bounds access to fields in the object, for example when you've overwritten the length field in an array object, you can't access any memory outside of the given Gigacage. This is explained well in the code here and shown below.

In terms of objects still being allocated on the primary heap, it's quite limited but some interesting types are included.

For example this includes a significant number of the container objects used by DOM objects. 

This means there's still decent opportunities to exploit UAF's and OOB issues among objects stored on the Primary heap. There's a handy BugZilla issue which is used for tracking improvements to the Gigacage implementation. 

IsoHeap is another new memory allocation API, every object allocated using IsoHeap will be allocated in dedicated memory pages. This stops objects of another type being allocated in the same memory, helping to prevent to exploitation of UAFs by preventing attackers from turning them into Type Confusion issues. This feature is explained pretty well in this commit. 

In order to use IsoHeap, the WTF_MAKE_ISO_ALLOCATED_IMPL macro must be added to each protected object, this is defined in IsoMallocInlines.h which just changes the define based on whether IsoHeap is enabled or not. If IsoHeap is enabled the macro expands to the code defined here and is shown below. 

This defines the typed IsoHeap in use for each object - now when an allocation is made it will use memory contained within the 'directory' of pages related to it's type. This is done in static memory, separate from any of the other heaps. Objects with a different IsoHeap type will not be allocated within any of the pages within this directory. An example usage can be seen in the canvas element: https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/HTMLCanvasElement.cpp#L87

This prevents an object from being free'd, a reference to it being kept and an attacker grooming the heap in such a way that an object of a different type is allocated at the same memory address. 

Since IsoHeap is only being used for objects which use the macro, it's easy to grep for where it's being using it.

We can see that this has been heavily adopted, covering 399 object types in total (when ignoring the two lines output by grep for the macro names usage in defines).

 And surprisingly not a single DOM object is unprotected!

Functionality mirroring IsoHeaps has also been added to JavaScriptCore as IsoSubSpaces, these are SubSpaces within the primary heap space which are only used to allocate objects of a certain size. Any object can be defined to use an isolated SubSpace which will only store objects of it's size, the ISO_SUBSPACE_INIT macro can be used for this. This functionality was initially implemented in this commit. 

Currently only a limited number of objects are allocated in this way, shown below.

These SubSpaces are within the standard heap and are only segregated based on object size rather than by type as IsoHeap does. This means they give less security guarantees however given the currently very limited set of objects using it, this likely isn't much of an issue.

There's active plans to implement more IsoSubSpaces if the performance hit is found to be reasonable, to quote the initial commit: 'So far, this patch just puts subtypes of ExecutableBase in IsoSubspaces. If it works, we can use it for more things.'.

After Spectre and Meltdown were published some significant changes were made to how WebKit validates object types. As Spectre relied on branching security checks to be exploited, they've begun implementing security checks which do not require branch instructions. The way they've done this for validating object types is to 'poison' pointers with a set mask value.

For each type of object they separate out the type information and data information, the type information now includes a constant specific to that object class which is used to poison the data pointer. Any accesses to the data have the poison remove from the pointer before the access takes place. By making the poison values large enough they can cause any invalid poison values used to reference unmapped memory. An example of this can be seen in the implementation of JSWebAssemblyTable.

Any accesses to the 'm_table' field are going to require unmasking the pointer to it. This makes exploitation of type confusion issues harder as if a poisoned pointer is accessed with the poison value from the wrong type, it will resolve to unmapped memory, crashing the process. 

The poison generation code can be found within WTF/wtf/Poisoned.h. The implementation of this is shown below, this shows how the poison values are generated in such a way that they don't generate valid pointers:

This is explained well on the WebKit blog. I'm unsure how complete this mitigation is and haven't dug into the practical implementation or status of it in depth.

In summary these changes severely limit the impact of DOM based UAFs, make the exploitation of OOB read/write issues more challenging and makes exploitation of at least a significant subset of type confusion based issues harder. Representing a substantial ramp up of the difficulty in exploiting WebKit based browsers such as Safari.

Mitigations within JavaScriptCore are somewhat lagging behind but significant improvements have still been made. This is understandable given that DOM based UAFs have historically been much prevalent and more commonly exploited.