Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Stack buffer overflow

stack

  • Please log in to reply
5 replies to this topic

#1 DarkLordCthulhu

DarkLordCthulhu

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 422 posts
  • Location:The bash shell
  • Programming Language:C, JavaScript, Bash, Others
  • Learning:Ruby, Others

Posted 08 January 2012 - 11:01 AM

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?
  • 0
Programming is a journey, not a destination.

#2 WingedPanther73

WingedPanther73

    A spammer's worst nightmare

  • Moderator
  • 17757 posts
  • Location:Upstate, South Carolina
  • Programming Language:C, C++, PL/SQL, Delphi/Object Pascal, Pascal, Transact-SQL, Others
  • Learning:Java, C#, PHP, JavaScript, Lisp, Fortran, Haskell, Others

Posted 08 January 2012 - 01:29 PM

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.
  • 0

Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

My MineCraft server site: http://banishedwings.enjin.com/


#3 DarkLordCthulhu

DarkLordCthulhu

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 422 posts
  • Location:The bash shell
  • Programming Language:C, JavaScript, Bash, Others
  • Learning:Ruby, Others

Posted 08 January 2012 - 03:13 PM

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?
  • 0
Programming is a journey, not a destination.

#4 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 08 January 2012 - 04:15 PM

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

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).

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.
  • 0

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#5 fkl

fkl

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 417 posts

Posted 09 January 2012 - 11:42 AM

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.
  • 1
Today is the first day of the rest of my life

#6 DarkLordCthulhu

DarkLordCthulhu

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 422 posts
  • Location:The bash shell
  • Programming Language:C, JavaScript, Bash, Others
  • Learning:Ruby, Others

Posted 11 January 2012 - 06:09 PM

Thank you, fayyazlodhi. You really cleared that up for me. +rep
  • 0
Programming is a journey, not a destination.





Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download