1. Context

The purpose of this project is to obtain an initial access during Red Team or Adversary Simulation exercises by gaining code execution through the exploitation of an integer overflow vulnerability in FireFox 56/57.

This write-up is written in two parts. The first part 3 describes how to take advantage of the memory corruption to control the instruction pointer by chaining several functions.

This second paper is about how to defeat mitigations and use arbitrary R/W primitives to reach our final goal: having a fully functional exploit.

Currently, there is not any write-up nor functional exploit published publicly.

That is the reason why, the development of this exploit was performed with the help of the ExodusIntel’s write-up 1 and other resources provided in this post.

To understand this paper, you need to have some knowledge of assembly with the usage of the stack and the heap and some famous techniques in browser exploits like Heap Spraying as well as ROP.

2. Exploit Development

First issue is that to trigger the code execution, we need to use an address which has execution permissions.

However, the Heap does not have these permissions because of the DEP protection and we are not able to perform code-reuse directly because of the ASLR protection that randomize the addresses we need.

In our context, the ASLR protection randomize all the base addresses like the base addresses of the libraries, the executable, the stack and the heap.

Moreover, with the DEP protection, only code sections of executable and libraries have execution flag but unfortunately those sections are not writable, we then need to obtain such primitives first to defeat DEP.

Therefore, a solution, that permits to execute arbitrary code, is, firstly find a way to bypass the ASLR protection in order to build a ROP chain.

Using this ROP chain, next step is to bypass the DEP protection by modifying the permissions on the heap and then execute our shellcode.

ASLR Bypass

A way to bypass the ASLR protection is to obtain a memory leak of an address and, after that, to be able to calculate offsets and find function addresses that will permits to craft our rop-chain later.

Memory Leak

At first sight, we can find a leak in the get() function and more particularly in the putNewInfallibleInternal() sub-function.

Indeed, in the Figure 1, the program will move the value of EAX at an address which is stored in the ESI register.

Moreover, another juicy thing is that we control both the ESI and the EAX registers which contains an object address located inside the Heap.

We can then dereference an object address through our Heap Spray with ESI pointing at an address within the Heap.

Furthermore, this address points to an address of the xul library. After that, with this address, we can calculate the base address of the xul library and, then, use xul code in a ROP chain.

Now, to reach this putNewInfallibleInternal function, we need to do the following call chain:

In fact, the putNewInfallibleInternal function is called by the putNewInfallible function as we can see in Figure 3 with its assembly code in Figure 4.

Then, the putNewInfallible function is called by the putNew function in Figure 5 and with its assembly code in Figure 6.

READ MORE HERE.