Vuln: Use After Free
In many scenarios, buffer overflows are pretty easy to catch and even basic input checks are not always going to be leading to issues at that moment in time- so, if we can not find a buffer overflow- what is the next stage? Well, we can search for use after free vulnerabilities!
What is this task
This task requires that we find a valid UAF (Use After Free) vulnerability in the program, state why its an issue, and also explain how we can fix it and why we should not be using memory after it has been deinitialized.
Pre game thinking - Logic
UAFs are actually super easy once we get to the root of finding all occurrences of modifications or general free calls. If you need help with this, please view the page linked below to learn about manually tracing free inside of Windows applications.
What are we looking for
If we have the calls laid out and we can easily search for all references, basically we are looking first for the use of 'free' where 'heap_malloc' was used. From there, we want to look for the value freed that was pushed into 'free' then figure out if that same data is used right after.
How do we get there?
Well, we can go back to the server function that we analyzed which handled the HTTP POST request to /api/v2/login on the local server. The reason we go back to this, is because we saw malloc being used many different times and plus that area seems to be perfect for a plethora of vulnerabilities including the BOF we found and missing security checks for data input.
So lets check out the original area shown in the image below.
If we are in this area, lets pay attention to the way data was allocated. What value was pushed to the malloc call?
Analyzing the function for flaws
Lets check the following screenshot out which is the same exact area, a little bit further down, but still same area with the UAF vulnerability in plain sight.
Through this screenshot, we can track the way RSI is being used and if we analyze where RSI is being freed- we can easily find our answer.
Analyzing the free block
The block below includes the code that goes to freeing up memory and then calling a Windows API function.
Here, this code presents a Use After Free vulnerability because the register rsi is being pushed to rcx as an argument to the free function call. A few instructions later, and we use rsi as an argument to calling the WinAPI call to WideCharToMultiByte. Because there is no other use or initialization of rsi, rsi becomes a value that is uninitialized memory used.
Last updated