If you’ve subscribed to my channel for long enough, you’ll definitely know, what a buffer overflow is, and that it is used to take control of the stack pointer.
But with programming languages such as python or java, the memory management is out of the hand of the developer and taken care dynamically. This means, that it is harder for an attacker to create the buffer overflow in this sort of applications.
Are there other ways for an attacker to take control of the stack pointer, without using a buffer overflow? Let’s take a look!
Buffer Overflow
Buffer overflows can occur both on the stack and the heap. Stack based ones, can give you a way to manipulate the stack pointer and return pointer. The goal is usually to control the instruction pointer (IP) to change the flow of the code.
Some ways to control the IP that are specific to buffer overflows include:
- Tamper with heap memory allocation (like malloc).
- Overflow into a neighbouring data structure, the “classic” style, which I also show in the video mentioned in the beginning.
Non Buffer Overflow ways
There are other ways to control the IP.
The maybe most known term to me is the format string vulnerability. If you’re not familiar with it, I’d recommend watching liveoverflows video on it:
An attacker can use this vulnerability to “jump” around in the stack and overwriting the value in the address he “jumped” to via a pointer. This is not the best explanation, so I recommend watching the video above.
There even more ways, which include:
- Triggering a double-free
- Triggering a use-after-free
But what about .NET, Java, etc..?
Managed languages, which take control over memory management, are build in a way, such that memory corruption is supposed to never happen.
But there is more to it. These languages use a run-time, virtual machine or similar. I’m pretty sure most of you will be familiar with this image:
This is the Java Runtime installation/ download page. And like most run-times or virtual environments, it is written in native code. That is code like C, which is unmanaged.
Therefore the run-times are vulnerable to memory corruption bugs. Which is more fatal in my opinion.
It is more fatal, because more people use and trust these environments. Many JS Browser run-times were vulnerable to some use-after-free bugs, which is a large part of why browsers are now sandboxed from the OS.
Additionally some languages like C# allow for unmanaged code like this:
static unsafe void Main(string[] args) {
int var = 20;
int* p = &var;
Console.WriteLine("Data is: {0} ", var);
Console.WriteLine("Address is: {0}", (int)p);
Console.ReadKey();
}Which are subject to similar vulnerabilities as usual native code. With a fitting keyword: unsafe
Conclusion
While there are other ways to control the stack pointer or instruction pointer other than the buffer overflow way, they usually appear in native code, but not in managed code.
However, the managed code runs on environments built with native code and sometimes even offer a way to write unmanaged code. These parts can still be vulnerable to memory corruption bugs.
If you liked this article and want more, subscribe to my newsletter for weekly updates.
Let me know your thoughts down below.
