Logo
RSS Feed

πŸ‘‰πŸΌ Use-After-Free

Created: 11.05.2023

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.

img 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.”.

img

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.)

img 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?

img

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. img

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 πŸ₯€. img

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. img 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

Expand… Something here