Seeing Double: Exploiting a Blind Spot in MemGC

Figure 1 shows the proof-of-concept together with some annotations indicating the order of operations. The main action begins in step 3 with the invocation of setRemoteCandidates. This API expects a JavaScript array. As noted in Figure 1, things go awry during iteration through this array. Upon access of arr2[1], the getter method executes (steps 4-5), and this script is able to release the memory used by the object that arr2[0] originally referred to. The script then reclaims and overwrites the memory with attacker-specified data (step 5). The crash occurs when setRemoteCandidates continues executing and attempts to access the object originally referred to by arr2[0].

To complete this picture, we will need to understand a bit more of what happens under the hood when setRemoteCandidates processes its parameter. Its operation is as follows:

      1 - Create an internal array structure called a CModernArray<>.
      2 - Iterate over arr2. For each element, get a pointer to the element and add it to the CModernArray<>.
      3 - Iterate over the CModernArray<> and process each JavaScript object in turn.

CModernArray<> is a C++ class defined in edgehtml.dll. Crucially, it stores its data in a buffer allocated from the MemGC heap. To recap and summarize the operation of this proof-of-concept: edgehtml.dll iterates over arr2. In doing so, it first copies arr2[0] to a MemGC-controlled buffer belonging to a CModernArray<>. Then, when accessing arr2[1], the JavaScript object that was already copied from arr2[0] gets freed and reclaimed, even though an outstanding pointer is present in the CModernArray<>. The crash occurs when retrieving this pointer from index 0 of the CModernArray<>.

Taking all this information together, we can now appreciate how incredible it is that there is a vulnerability here at all. Throughout the process, all objects involved (JavaScript arrays, etc.) are allocated on the MemGC heap. Furthermore, all pointers to those objects are stored within MemGC-allocated arrays and buffers. How, then, could a UAF arise? A UAF of this sort is precisely what MemGC is supposed to prevent. MemGC is designed to be aware of all pointers present within the MemGC heap, so that no MemGC allocation can be freed while a pointer still exists. Within the realm of MemGC heap allocations, MemGC is supposed to be all-knowing and all-seeing. Why, then, does MemGC not detect the fact that there is an outstanding pointer present in the CModernArray<>?

These two heaps share an implementation, but they are represented by two separate instances of the class chakra!Memory::Recycler. When garbage collection occurs, during the “mark” phase, the recycler scans all live heap allocations, as well as the stack and processor registers, for pointers to additional heap allocations so those can also be marked as live. Since not every value in memory is a bona fide pointer value, this scan will turn up some extraneous results. To help filter these out, Recycler will automatically reject any value that is outside the range of allocations belonging to the heap. However, this determination is only made on a per-heap basis. A Recycler instance has no knowledge of the address regions that may be in use by other Recycler instances. Furthermore, it has no ability to place “marks” on MemGC allocations belonging to other Recycler instances.

As an aside, there are even more than two MemGC heaps. Each thread of JavaScript execution has its own Chakra heap instance. Generally, this does not cause trouble because a JavaScript object does not interact with code on any thread except the one on which it was created.

We can now understand what occurs when running the proof-of-concept code in Figure 1. In step 5 (see figure), memory pressure forces garbage collection for the Chakra heap. This is performed by the Recycler instance associated with the Chakra heap. While scanning the stack, the recycler encounters the pointer to the CModernArray<> buffer. However, it immediately rejects this pointer, because the CModernArray<> buffer has been allocated on the DOM heap and not the Chakra heap. As a result, the Chakra heap’s Recycler never scans the contents of the CModernArray<> buffer, and consequently, it misses the outstanding pointer to the Chakra-heap-allocated object contained therein.

It is also instructive to consider the patch. Now, before adding each object to the CModernArray<>, edgehtml makes a call to chakra::JsVarAddRef to explicitly pin the object in memory. See edgehtml!ORTC::UnpackArrayObjectVar. MemGC falls on its sword in this case, and the code in edgehtml must resort to manual object-lifetime management.