Is it possible to overwrite% eax using buffer overflow?

Question

I know that the software stack looks something like this (high to low):

EIP | EBP | local variables 

But where can I find %eax and the rest are common registers? Is it possible to overwrite them with a buffer overflow?

Update: in the end, I didn’t even have to rewrite %eax , because it turned out that the program indicated %eax to enter the user at some point.

Answer 1

The register, by definition, is not in RAM. The registers are on the CPU and have no addresses, so you cannot overwrite them with buffer overflows. However, there are very few registers, so the compiler really uses them as a kind of cache for the most used stack elements. This means that although you cannot overflow stricto sensu registers, values ​​overwritten in RAM will be loaded into registers sooner or later.

(In CPU Sparc, the register-stack-cache policy is even tightly bound.)

In your scheme, EIP and EBP are not on the stack; the corresponding slots on the stack are the areas from which these two registers will be reloaded (after the function exits). EAX, on the other hand, is a general purpose register that will be used here and there without strict agreement.

Answer 2

EAX will probably never appear on the stack. For most x86 compilers, EAX is a 32-bit register of return value and is never stored on the stack or restored from the stack (RAX on 64-bit systems).

This does not mean that buffer overflows cannot be used to modify the contents of an EAX by pushing executable code onto the stack; if the execution of the code on the stack was not disabled by the OS, this can be done, or you can force the stack a dummy address that transfers control to the code sequence loading the value into EAX, but it is quite difficult to pull it out. Similarly, if it is known that the value returned by the function is stored in a local variable, the stack partition that changed this variable would change the value copied to EAX, but optimizing compilers can change the structure of the stack on a whim, so operation that works on the same version may complete with a new version or patch.

Answer 3

See Thomas Pornin (+1) and other answers (+1), they are good. I want to add an additional answer that could be referenced, but not specifically specified, but this is a spill of registries.

Although the "where" of the original question (at least as indicated) is based on the false assumption that% eax is on the stack and being a register, it is not part of the x86 stack (although you can emulate any set of hardware registers on the stack, and some architectures do this, but it doesn’t matter), by the way, registers often spill / populate from the stack. Thus, it is possible to split the register value by overflowing the stack if the register was spilled onto the stack. This will require that you know the distribution mechanism of a particular compiler, and for this function call you would need to know that% eax was spilled, where it was spilled, and stomp this stack location, and when it will be next filled from its copy of the memory, he gets a new meaning. As unlikely as it seems, these attacks usually inspire reading the source code and knowing something about the compiler in question, so this is actually not so bad.

See this for more on register spills.

gcc register scatter on x86-64

https://software.intel.com/en-us/articles/dont-spill-that-register-ensuring-optimal-performance-from-intrinsics