Getting exploit reliability when using the off by one framepointer overwrite on linux

Question

We have a program that is vulnerable to a one byte frame pointer overwrite. The stack is marked executable, the Linux machine has aslr disabled, stack cookies are disabled, and it's a little endian standard x86.

We may run:

buf[256];

for(int i=0; i <=256; i++)
  buf[i] = argv[1][i];

However, I want to put my shellcode into buf and then jump to it. If I would use a normal stack overflow, I could get exploit reliability by going to a loaded library which has the jmp $esp instruction somewhere encoded, and then put my shellcode where the function arguments are and so forth. But this is not possible here.

So what do you do if it's a remote process (you can't hardcode the address values) and need exploit reliability? The only thing that came to mind is stack alignment where we could be able to predict the low bits (2 or 3 bits maybe?).

I just need to know the low byte of the frame pointer so I can overwrite it with a little smaller value control eip to point to jmp esp and at the instruction at esp would be like a short jump -0x80 or something such as that.

I have decreased the frame pointer => ret gets executed => control eip => point eip to jmp esp instruction => next instruction is the short jump -0xsomevalue execution => payload gets executed.

I thought about other heuristics like writing the pointer to jmp esp over and over into the buffer so that it's more likely to get control of eip, but that way my method of jmp -0xsomevalue wouldn't work anymore.

Answer 1

I had an extremely similar homework problem that I had in a security class. The reliability of your exploit depends on how large the buffer is. If you are overflowing a particularly large buffer, then your exploit will have a larger chance of working.

Here is how your exploit sandwich should be structured:

[NOPS][Shellcode (usually about ~60 bytes)][FP overwrite]

As you know, you will only be able to overwrite the last couple of bits of the Frame Pointer. This will cause the EIP to point into your sled if you are lucky enough. If you have a buffer of size 265 like in your example, here is how a good sandwhich would look:

[NOPS * 150][Shellcode][FP overwrite] << FP Overwrite MUST be at index 256

Now as I said, the reliability of your exploit is going to rely on the size of the sled you can produce. If you buffer is 1024 bytes, then your exploit will be very efficient.

If you come up with a good value for your Frame Pointer overwrite, then you are going to have a lot more success with your exploit. Also creating the largest possible sled is going to be key here as well. For this exploit, it is probably safe to use:

NOPS = (size of exploited buffer + 1) - length of shellcode - 1

simply:

NOPS = (size of exploited buffer) - length of shellcode

This will give you the largest change possible of landing in your NOP sled. Now just play with the FP overwrite value and find a value that is pretty consistent.

helpful info on off-by-one errors:

• http://en.wikipedia.org/wiki/Off-by-one_error

How a nop sled works:

• https://stackoverflow.com/questions/14760587/how-does-a-nop-sled-work

Here is the article I had to read for my class, it was really helpful:

• http://insecure.org/stf/smashstack.html

Answer 2

Creating reliable exploits requires time and patience and lots of debugging.

I think what you are looking for is a NOP Sled or NOP Slide. When you execute the short jump you need to land it in the middle of the NOP Slide, so the execution then slides through the NOPs to your shellcode.

Check out this site for a detailed breakdown of exploit writing.