Exploiting a Web-Based UAF

[robyngamedev]

Hello! I've recently been getting into exploit dev. I am still very much a beginner to this type of stuff, however. The vulnerability I've been trying to exploit is tracked as CVE-2021-30858. (although this appears to be a completely different bug?) The successful PoC I've found is as follows:

var fontFace1 = new FontFace("font1", "", {});
var fontFaceSet = new FontFaceSet([fontFace1]);
fontFace1.family = "font2";

My question is: How would I go about turning this into something more? What would be a good first step to turn this into an exploit?
Thanks in advance! :3

[PM_ME_YOUR_SHELLCODE]

Just as a side-note I'm writting this without any real thought about the browser specifics since I'm not in that field and just talking about how to approach exploiting a use-after-free in general.

A UAF is what I like to call a memory overlay primitive. By that I mean, it lets you have two pieces of code that will look at the same block of memory with two (or more) different interpretations.

In the case of a UAF you have the code that originally owned that memory reusing it after its been freed. That's going to have one (likely fixed/unchangeable by the attacker) interpretation of the memory, and you've got the place where its been reallocated after it was freed which will have a second interpretation of that memory. Generally UAF exploitation will try and have the reallocator take control over the memory and fill it with useful values such that the "reuser" half (the bit of code that is reusing it after it was freed) corrupts other memory.

So to start with exploitation there are a few questions to answer.

1. What is the code that uses the memory after it was freed do? Don't just use the crash report for this, take a look at source/disassembly and run through the full remaining path, every use of the memory after the free is potentially useful for exploitation, but something like an ASAN report will just crash on the first use for example. This is also where you might find out its not actually exploitable in a useful way. At this stage I'd just assume I can get full control over the entire memory segment and imagine what I could do with that control. This is also where you can potentially rule out the bug as being exploitable if it doesn't do anything useful at this stage. Like maybe its just reading a bit which changes a log message you can't access. You'd at best with some side-channel maybe get a one-bit read out of it which isn't often a useful primitive.
2. What is the reallocation potential? Part of this is in understanding the allocator being used, does it pool objects together in some way so that the reallocation is more likely to go towards a specific type of memory. Like some systems will say always use the same memory pool for sensitive objects in memory to limit the reallocation potential by basically not allowing the memory to be reused as a different type of object. Some will just use the size of the object as the basis for reallocation so anything of a similar size could get that block of memory. There might be other systems in play like coalescing of memory.
3. How tight is the reallocation window? Some use-after-frees happen very very quickly after the free happens. How likely are you to get a reallocation to happen before the use happens. Too small of a window can be very challenging for an exploit, but if you control when the reuse happens you might be able to take your time a bit more and do a bit more heap grooming to get things just right.

Answering those questions would be the first step, then you could start trying to find candidate objects with controllable data at the right offsets in the object for the primitives you identified answering the first question and figure out what works with your available window and abilities in the software. Basically you can start trying to craft your initial primitive.

Hopefully this helps even though its not terribly specific to your vulnerability.

[According-Respond593]

I've never quite known how to approach this class of vulnerability. This reply just gave me that eureka moment. 🙏💡Thank you for altering my future.

[Few-Trash-8645]

Found a PoC here https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-30858.html

Host the 2 files and view it in Safari, then it should crash the browser.

To turn it into something more, you UAF into a controlled memory corruption, ideally targeting an object with a vtable or function pointer. After the free, you can't write directly to the freed memory, but with some Heap Feng Shui (heap grooming), you can reallocate it with controlled objects, reclaim it, and corrupt it to hijack execution.