This is for a Computer and Network Security class. I am not asking for the solution, rather just a pointer in the right direction.

The target program has an off-by-one vulnerability and is compiled such that ebp is not pushed on the stack. By attacking the vulnerability, I am able to change the last byte of the eip and effectively send the program to any instruction in the program.

My question is, if I place some malicious code in the exploit program (that calls the target program via an execve), can I change the eip to point to this malicious code, or is the runtime smart enough to know that I am attempting to execute code that is located outside the bounds of the target program and thus, not allow it?

The environment is a stripped down Debian Etch VM with no ASLR etc. The target program has setuid set to root, so my goal is to get the target program to execute instructions that pull up a shell (giving me root shell).

1 Answer
1

From the point of view of the kernel, memory space is split into pages (typically 4 kB per page). Each page has access rights, like "can be written to", "can be read", "can be executed" or "cannot be accessed / not here". The kernel will not mind in any way as long as you jump into a page which is marked as "can be executed". If you alter only the least significant byte of eip, you will fall into the same page than the original caller, so the jump will be allowed. Of course, if you jump into bytes which do not make sense as instructions, things will go sour pretty fast...

(Note: on 32-bit x86 CPU, with usual operating systems, there may be no difference between "can read" and "can execute" for pages; it is a quirk of the Memory Management Unit used in the early 32-bit x86 CPU.)