execve 缓冲区溢出成功完成后的 CPU 执行流程？ ..int 0x80 成功完成后？

Question

I'm learning about buffer overflow shellcode methods under Linux. https://seedsecuritylabs.org/Labs_16.04/Software/Buffer_Overflow/

The shellcode I've used ends with movb $0x0b, %a1 and then int $0x80. The shellcode executes and I get my command prompt. I've read many places that execve and int 0x80 "do not return". Well.. okay, but where ~does~ program execution flow go when execve process succeeds and exits (aka I enter "exit" on the command line prompt)?

I thought the calling program has its stack frame replaced with the new execve code's information. Does the new execve code preserve the return address of the overwritten process and return to that address as if it were its own? (So it does sort of return .. to a borrowed address?) As far as int $0x80 goes, doesn't execution continue at the next byte after the int 0x80 instruction? If not, what next byte?

In context of the buffer overflow problem and int 0x80, say (for example) a 517 byte hack overwrites a 24 byte buffer. Bytes will replace values at stack memory addresses beyond the buffer, including return address pointing to its own executable code higher up in the stack. But the intentional code stomps on 100s of other stack bytes higher in memory, destroying stack frames of unrelated outer-scope processes. With these destroyed stack frames, what happens when...

1) when the shell returns from the int 0x80 and executed more stack data that is not part of the hack. What's there is now unspecified bytes that are probably invalid CPU opcodes.

2) context of outer stack frames have been destroyed, so how does the system gracefully continue after I enter "exit" at my shell command prompt?

Any help appreciated!

Answer 1

I think you'll understand what is going on if we discuss what execve is and how it works.

I've read many places that execve and int 0x80 "do not return". Well.. okay, but where ~does~ program execution flow go when execve process succeeds and exits (aka I enter "exit" on the command line prompt)?

The following is from execve 's manpage.

execve() executes the program pointed to by filename.  filename must be
       either a binary executable, or a script starting with  a  line  of  the
       form:

           #! interpreter [optional-arg]

execve is a system call which executes a specified program.

Continuing,

execve() does not return on success, and the text, data, bss, and stack
       of the calling process are overwritten by that of the program loaded.

This statement deals with your question.

Every process has it's own memory layout. Memory layout consists of text segment, data segment, stack, heap, dependent libraries etc., Refer to /proc/PID/maps of any process to get a clear picture of memory layout.

When execve is executed and it succeeds, the complete memory layout is erased (contents of the caller process is lost forever) and contents of the new process is loaded into memory. New text segment, new data segment, new stack, new heap, everything new.

So, when you try to exit on your command-line, you'll just terminate /bin/sh which you had run using execve. There are no seg-faults, no errors.

Does the new execve code preserve the return address of the overwritten process and return to that address as if it were its own? (So it does sort of return .. to a borrowed address?)

No. This doesn't happen. The new process launched by execve has no clue about the old process.

As far as int $0x80 goes, doesn't execution continue at the next byte after the int 0x80 instruction? If not, what next byte?

int 0x80 instruction is present to request the OS to execute a specified system call. So, whether execution continues later once int 0x80 returns totally depends on what the system call is .

Generally, read, write, open, creat etc., all execute and return back. But, the exec class of functions(go to man exec ) are different. Each of those functions never return on success. They return only on failure.

The last part of the question, because the memory layout has been erased and new contents are loaded, there is no sign of buffer-overflow here, no memory corruption.

I hope this answers your questions.