👉🏼 Use-After-Free

This article is about use-after-free vulnerability, its mechanics and how it can be used for evil things. Several things could be done by using this vulnerability, for example, reading sensitive info or arbitrary code execution. The exploitation often requires the presence of some other vulnerability as well, for example, buffer overflow (not always).

Mechanics

Computer stores data in either of two places: heap or stack. The stack is relatively small, so only a little is stored there (although it does not mean any less valuable). While buffer overflow is more of a concern for the stack, this vulnerability is the heap’s 💩 headache.

So, imagine you have a pointer 🌻 pointing to some 🌴 object on the heap 💩 that will say, start doing good. Some address space is allocated for this data structure, all good.

Now, the program thinks it doesn’t need that object anymore and says to the OS: “Hey, OS, you can choke on that address space, I don’t need it”. But the OS is not made of flimsy material and just says, “Eh, whatever, I am busy. Five minutes.”.

So, it just puts the broom 🧹 by the address space and forgets about it (“Why bother? when the space is needed, I will overwrite it”, it thinks.)

Now, another object is created, a 🥀 beautiful rose. It carries a message “Cease doing good, start doing evil.”. The developer doesn’t intend to use its horrible and distructive function, but he only needs its petals. As it does for any other object, OS allocates new space for that 🥀 object. But remember, it’s lazy. It doesn’t go far. What’s the last memory freed and thus the closest?

It does not mean that it will ALWAYS be the same address space, but the possibility of that can be increased, for example, if the attacker allocates a lot of room for their data. For the fun’s sake, let’s assume that we are sure that the address space newly allocated is the same.

Now, we create another object, new pointer pointing to the same location.

Now, asign the new value to this old-new location. Let’s say it now says “cease”. There is a new 🥀 pointer now, which is pointing to the same location. The “start” gets overwritten. But the thing is that the first pointer 🌻 is still pointing to this location. So, you can now access this memory area in two ways: 🌻 and 🥀.

Now, let’s assume that the developer forgot he freed the space and using the first pointer 🌻 again. He would expect to get “start”, since that’s what we put there, when in reality he’d get “cease”, since the new pointer has already changed the value at this location. Use-after-free vulnerability doesn’t necessarily require overwriting values. One could instead read the data they were not supposed to read.

Pseudocode

class 🌻 UserSunflowerData{
	 char seeds[100];
	 public void bloom(){
		 # some code
	 }
}

class 🥀 UserRoseData{
	char petals[100];
	public void loose_petals(){
		 # some code
	 }
}

int main() {
	🌻 sunflower = new 🌻 UserSunflowerData();
	🌻 sunflower->bloom();

	free(🌻 sunflower)

	🥀 username = new 🥀 UserRoseData(input("What's your username, pal?"));
	
	🌻 sunflower->bloom(); // expected to run bloom, but might run 🥀 UserRoseData->loose_petals() instead if the same memory location was reused.
}

Now, imagine that the attacker has control over the 🥀 username. For example, they are prompted to enter their desired username. Now, imagine that data is physically located exactly in the same place where the 🌻sunflower used to be. One would expect to see the 🌻 sunflower->bloom, but will instead see 🥀 rose->loose_petals.

Examples

Microsoft Explorer had this vulnerability long time ago.

References