简体   繁体   中英

Stack Overflow corrupt %ebp

I'm trying to study for an exam, and looking over stack overflow stuff i was hoping someone could clear something up for me. (assume this is on a 32 bit system, so that all addresses are 4 bytes. Also I am studying it from a C function, so any code referenced is from C)

Say our code wants to take in buf[4] from standard input, and so it creates a four byte buffer. If we use the version of gets() that does not check for out of bounds, and input the string "12345" we will corrupt the saved %ebp on the stack. This will not, however, change the return address. Does this mean that the program will continue executing the correct code, since the return address is correct, and it will still go back into the calling function? Or does the corrupted %ebp mean trouble further down the line.

I understand that If we input something larger like "123456789" it would also corrupt the return address, thus rendering the program inoperable.

EBP is the base pointer for the current stack frame. Once you overwrite that base pointer with a new value, subsequent references to items on the stack will reference not the actual address of the stack, but the address your overwrite just provided.

Further behavior of the program depends on whether and how the stack is subsequently used in the code.

What exactly is corrupted heavily depends on generated code, so this is rather compiler and settings dependant. You also don't know if really ebp would be corrupted. Often compilers add additional bytes to the variables, so with one byte overrun nothing might happen at all. On newer Visual Studio code I saw that some safeguard code is added, which causes an exception to be thrown.

If the return address is corrupted, this can be used as an entrypoint for exploits installing their own code.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM