5 replies to this topic

[DarkLordofthePenguins]

I've read about how stack buffer overflow is used to run malicious code, and there are some things I don't understand. I know we're not supposed to ask questions about how to crack, so I apologize if this is in violation of that rule. I'm not trying to learn how to write malware; I just want to understand how this works.

As I understand it, basically a program enters more data into another program's input buffer than it can handle, causing a stack buffer overflow which causes the stack pointer to point to the code for the malicious program. The CPU then executes that code.

Here's the problem: The stack pointer doesn't point to executable code; it points to data, and the data it points to is not interpreted as code. The CPU executes the code pointed to by the instruction pointer, not the stack pointer. Why would a CPU execute the contents of the stack? That's not what it's designed to do. You would have to have the stack pointer point to a pointer to the malicious code and then load that address into the instruction pointer.

Also, I read that newer Intel and AMD CPUs have fixed this problem by adding a security feature that prevents code in the stack segment from being executed. I don't see why this is necessary, seeing as the instruction pointer contains an offset within the code segment and can't point anywhere else. It's impossible for the stack pointer to point to code in the code segment and it's impossible for the instruction pointer to point at the stack. Why, then, is it necessary to protect the stack from execution?

[WingedPanther]

Generally, this results from using C-style strings implemented with pointers that don't have proper checking to avoid over-running the string. If you do over-run the string buffer length, then you can be over-writing code such as functions used by the application.

[DarkLordofthePenguins]

WingedPanther said:

Generally, this results from using C-style strings implemented with pointers that don't have proper checking to avoid over-running the string. If you do over-run the string buffer length, then you can be over-writing code such as functions used by the application.

I still don't understand, though. The data buffer and the code are in completely different segments. How can one overflow into the other without generating a segfault?

[Alexander]

Quote

As I understand it, basically a program enters more data into another program's input buffer than it can handle, causing a stack buffer overflow which causes the stack pointer to point to the code for the malicious program. The CPU then executes that code.

Here's the problem: The stack pointer doesn't point to executable code; it points to data

Quote

I still don't understand, though. The data buffer and the code are in completely different segments. How can one overflow into the other without generating a segfault?

The point is to write past what is allocated in to an instruction pointer (IP) or extended instruction pointer (EIP) for 32-bit 8086 processors located thereafter. If it is filled with garbage data (for example '1234' from user input) it will cause a segmentation fault as whatever 1234 is in ASCII as a memory address will not belong to the program (hopefully).

Quote

Also, I read that newer Intel and AMD CPUs have fixed this problem by adding a security feature that prevents code in the stack segment from being executed. I don't see why this is necessary, seeing as the instruction pointer contains an offset within the code segment and can't point anywhere else. It's impossible for the stack pointer to point to code in the code segment and it's impossible for the instruction pointer to point at the stack. Why, then, is it necessary to protect the stack from execution?

Data execution prevention (DEP) is useful and can prevent the most simple exploits (i.e. read the (extended) stack point where it may point closely to the payload and run it) however code can be stored in the heap, in a file in memory that belongs to the application and I am sure there are a few other ways. You'd have to research this yourself to find similar vectors. A lot of operating systems or code still allow code to be executed in the stack.

[fayyazlodhi]

DarkLordofthePenguins said:

As I understand it, basically a program enters more data into another program's input buffer than it can handle, causing a stack buffer overflow which causes the stack pointer to point to the code for the malicious program. The CPU then executes that code.

Here's the problem: The stack pointer doesn't point to executable code; it points to data, and the data it points to is not interpreted as code. The CPU executes the code pointed to by the instruction pointer, not the stack pointer. Why would a CPU execute the contents of the stack? That's not what it's designed to do. You would have to have the stack pointer point to a pointer to the malicious code and then load that address into the instruction pointer.

I would give a simpler example for you to see the problem. Stack points to data, but it is not the only thing. With every function call, before the function parameters are pushed on the stack, there is another thing pushed. This is the return address i.e. the address of code in code segment from which the current function was called. Suppose a field that i do a buffer over flow with is next to return address, in fact it doesn't matter where it is as long as i can figure out where in the stack was the return address pushed.

Now i have written a malicious function, and i copy it's address IN PLACE of the return address. This would give my program the illusion that the current call in stack was made from my malicious function and after returning from current function it would start executing the malicious code though the code is actually lying in the code segment.

In C it is much easier to do this, since you have pointers with freedom to go across the memory. All that is needed is knowing and correctly doing the arithmetic to locate and over write return address. With other languages in which pointers don't exist, weaknesses such as possible buffer overflows are the only source of triggering such vulnerabilities.

Hope that helps and this was just one instance, there are other ways too.

[DarkLordofthePenguins]

Thank you, fayyazlodhi. You really cleared that up for me. +rep