Buffer Exploits — maintaining space can lead to breakups!
In modern computer science, C++, being robust and flexible general-purpose programming language, is used to develop operating systems, browsers, games, and so on. Due to its imperative and object-oriented features, it is widely used by programmers and developers, mainly in the application domain. It relies on the programmer to allocate memory and by which it is more susceptible to buffer exploits.
What is a BUFFER?
The buffer refers to a block of a computer memory that serves a temporary placeholder.
In other words, Memory locations for storing temporary data that is being used while the program is being executed. We will be focusing on the stack because that’s where most of the buffer exploits happen.
Basic stack layout
Say you have a beautiful program implemented using functions, these functions do some task, return us with something and go to the address from where this function was called. During this process the stack of our program’s memory gets filled downwards with the calling function, it’s parameters, the return address, the reference to the function, a base pointer, and anything after these is allocated to the buffer in the stack.
But the space for the buffer is preserved and limited to a certain memory. So when you or I give input for the variables which attempt to put more data than the buffer can hold. What do you think will happen? Ping ping ping…
What’s the Issue? How can this be used as a Hacking tool?
When you try to pour water in a cup that is already filled, the water of yours gets poured on the floor.
A buffer overflow condition arises when the data exceeds the buffer limit. These are also responsible for some basic bugs such as Glitches in games. Buffer overflows are not easy to discover, and even when one is found, it is generally challenging to exploit. Nevertheless, attackers have managed to identify buffer overflows in a staggering array of products and components. There are several other advanced techniques (like code injection and execution) through which buffer overflow attacks can be made. Still, it is essential first to know what buffer overflows are, what dangers they pose to your system, and what techniques attackers use to exploit these vulnerabilities successfully.
What can cause buffer overflow?
If you have better experience in programming, then I assume you might have tried programming a simple login system, in which you want the user to enter his username and password. The input for the username is going to be a string data type, say you declare a string of 256 bytes with an assumption that the user will not enter his username more than 256 characters.
As a user, I enter my username containing 300 characters, which exceeds the actual memory allocated for the username variable this causes the remaining data which is 44 bytes getting allotted to other variables, and hence the behaviour of the program changes. In this case, it doesn’t look like a serious issue, but this practice can cause worse consequences than you think.
To understand better, let’s look at an example.
When the function callUser gets called, the argv[1] value, the memory address for line 14 as the return address, the base pointer to refer parameters and local variables get pushed to the stack and buffer of 100 bytes long is allocated in the stack followed by a call to strcpy
When we run this program on command-line with the parameter “Thrishik”, the program has taken ‘Thrishik’ into the buffer and output “Welcome Thrishik” gets displayed as expected.
Now, Let’s break the code.
Let’s send a long string of 108 characters this time, with 100 times the letter ‘A’, four times the letter ‘B’, and another four times the letter ‘C’. The input we will be passing will be “\x41”*100 + “\x42”*4 + “\x43”*4. Where 0x41, 0x42, and 0x43 are the hexadecimal values of 65, 66, and 67, which refers to the ASCII-code of ‘A’, ‘B’, and ‘C’ respectively. This long string is passed as an argument for the username in the program.
So we get a segmentation fault this error is sent by the CPU when we try to access a part of memory that shouldn’t be accessed, and in our case, it was because the return address is overwritten with (0x43434343) which is nothing but the 4 C’s in our input. This 0x43434343 is pointing to the return address, but it is empty which doesn’t belong to the program, so we are not allowed to read it, and hence we get question marks and segmentation faults. Doing this, we can change the return address, which is something important to look at.
How is it hacking?
By this technique, attackers can send large string containing shell codes as input. And these shellcodes can change the return address to the address of some malicious script which can do something beneficial when executed. Attackers are easily gaining access to the system. They can also try deleting or updating data which causes severe problems to the developer and in some instances, it can also lead attackers to read passwords at higher privileges.
Let’s dive into something deep.
Let’s say we have our shellcode somewhere in the buffer, and we need to point the return address to this shellcode, what do we do? In assembly language, we have ‘/x90’ which represents no-operation instruction aka NOP SLEDS, which are sent as a sequence with the shellcode and some return address as input. At runtime this allows CPU’s instruction executions to slide towards the shellcode. The return address in the stack should be changed to somewhere in the buffer itself so that it lands on the NOP-sled and starts sliding along the buffer until it hits the start of the shellcode.
Can we use this in the command-line to gain access to the machine?
Yes, Once the attacker finds an exploitable vulnerability (not only through buffer overflow it can be anything ) in the user’s program, it’s easy to get root privileges by which they can have access to password files.
How to Prevent this?
It all depends on how the user sends his input. In that case, the programmer or the developer should have an eye on the length of the input. It is better to avoid using unsafe functions such as ‘printf’, ‘strcat’, ‘strcpy’, ‘gets’ these can lead to a buffer overflow. ‘fgets’ similar to gets function is the only safe function provided by C language. Or you can stick to using other secure functions that include buffer overflow protection which is available in different platforms, for example, strcpy_s, strcat_s, sprintf_s (Windows).
To further avoid buffer overflow, you can add extensions on the compiler such as ProPolice, StackGuard which uses ‘Canaries’. The Canaries are special values placed on the stack between the location of the buffer and the location of control data. When these canary values are destroyed by stack buffer overflow, it indicates that the buffer in the memory has been overflowed. Verifying the canary value, execution of the affected program gets terminated, preventing attackers from taking control over the system.
If you are still unsatisfied, I recommend you change your programming language to interpreted languages like Java or Python which are immune to these attacks (except for the overflows in the interpreter itself). Web applications and web pages are rarely vulnerable to these attacks because they provide built-in protection towards accessing and against overwriting data.
Let’s Conclude
Stack-based attacks are rare cases today, but they do exist. As systems show huge growth, there are many new operating systems getting released, unlike Windows or Linux, which have weak security systems. Due to which smaller groups that pay no attention to security still release malicious codes to exploit operating systems. And hence it’s essential to keep these points in mind, while programming with low-level languages.
If you want to try this in your system, I recommend you to test it with an in-built debugger first.
SOURCES
Those who were patient enough to read through the entire article here are some resources for the curious mind.
This article is published as a part of the Hacker Series under Spider Research and Development Club, NIT Trichy on a Web Wednesday!
