How bad is a buffer overflow?
Most programming languages now allow programmers to create procedures. Learn more about these terms & notice that they happen to be a form of automation.
When you write a function, you are essentially writing a self-contained code block. It can hold some data, process it and return some other data then used by the program. At a function called, the original program interrupts its flow in favor of this new piece of code. To return to this previous state, we have to somehow execute some kind of function.
This is done by storing the necessary information in an area of memory known as the stack. First, information is the state of the registers before the function was called and the memory address from which the program flow must continue after the function is finished. Finally, stack stores data within a function like internal data used by a function.
We know stack-based programming structures as LIFO. Think of a stack of dishes that hasn’t been washed yet: the first dish on the bottom will be washed last. In this case, all relevant information discussed are visible at the bottom of the stack. In case the function handles a buffer (it is a piece of memory, usually a character array) it may, by “programmatic carelessness”, the latter may overflow. Commonly we have a buffer overflow.
The simplest case is copying data into a buffer without checking if it is big enough to hold it. The immediate consequence is that the overwrite of extra data onto the stack. Remember that that’s the location of the storage of the buffer the function manages. This also contains the return address.
There is a high probability of changing this address. That’s why anyone can create a buffer by the computer. Any remaining data stored in it before the program will continue to flow from a memory location selected by chance. In case of not intentional “overflow”, the program will try to execute instructions from an “inappropriate” area. The consequences of that are a beautiful crash.
So what’s the problem with deleting return addresses from the mail? It can cause the program to execute your own code by accident. At this point, let’s analyze a scenario. You want to access any account on a website or send requests in bulk emails only you could see. Now, this is just too easy. And the final question is the hottest. Where and how do we store our own code, so that we can know where to look for it? The answer is simple. You will enter the offending code in the buffer which will overflow and modify the return address by adding a bunch of content to it.
Imagine if you had a program to help you change the name of a file. You tell the program what file’s name you want to change, and then it changes the name on your computer. It only takes seconds to perform thousands of tasks like this. In case a copy of the information arises into a buffer during the program, you can achieve overflow. If, now, instead of a filename you provide the necessary code to “open” a root shell, you can take advantage of buffer overflow in an obvious way.
Of course, before direction to a shell with root privileges, the latter must pre-exist. This is why buffer overflows are disastrous when they occur in programs that have the root user id (suid root) enabled. The program that changes the name of a file has no reason to be suid root, so there are no immediate risks from a vulnerability. But if we had pppd, passwd or sendmail (all running as suid root) in its place, then enabling a root shell via an overflow would be possible.
In practice, things are a bit more difficult, although basically writing an exploit that exploits a buffer overflow is… formulaic. The would-be cracker, having identified the weakness of a program, has to do several calculations to find out the “distance” that the return value has from the buffer to be overflowed. Also involved in the game are several issues around computer architecture, where we are dealing with different stack management.
Unfortunately, the technique is so widespread that the only solution is careful planning. For our part, we have tried to analyze the technique as subtly as possible, so that those who want to learn and protect themselves from crackers understand what to guard against, and would-be crackers don’t find an article of this form: “Write a step-by-step exploit”.
If you liked this article, then you may also enjoy this one.
Author: PC-GR
The World of Technology
