-1

I'm trying to retrieve the offset of the Ret Address during a simple buffer overflow by using a cyclic pattern created in gdb-peda. I would expect a sigsegv on the return to callee frame, but I got it during the printf of the injected buffer.

I'm working with an x86 kali linux. I can figure out that my retaddress is away 264 bytes and I was able to exploit the program by rop-ing. I would like to evaluate the RET address throughout a cyclic pattern and thus I used in gdb-peda

gdb-peda$ pattern_create 300 tmp.txt 

to create the pattern. Finally I launched my binary as:

gdb-peda$ r `cat tmp.txt`

ASLR is disabled and the binary compiled as:

gcc -mpreferred-stack-boundary=2 rop.c -o rp    

here it is the rop.c program:

int main(int argc, char *argv[])
{
    char buf[256];

    strcpy(buf, argv[1]);
    printf(buf);
}

I would expect a sigsegv at the return of main with ESP pointing to a segment of the cyclic pattern releaving the offset of the RET address, instead I get a SIGSEGV during the printf. I'm reporting peda output:

gdb-peda$ r `cat tmp.txt`
Starting program: /mnt/hgfs/SSI/ROP/rp `cat tmp.txt`

Program received signal SIGSEGV, Segmentation fault.

[----------------------------------registers-----------------------------------]

EAX: 0x41414241 ('ABAA')
EBX: 0xb7fbe000 --> 0x1d4d6c
ECX: 0x0 
EDX: 0x1 
ESI: 0xb7fbed80 --> 0xfbad2a84 
EDI: 0xe0 
EBP: 0xbffff118 --> 0xbffff248 ("%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA")
ESP: 0xbfffec0c --> 0xb7e338d2 (<_IO_vfprintf_internal+8322>:   add    esp,0x10)
EIP: 0xb7e8163f (<__strlen_ia32+15>:    cmp    BYTE PTR [eax],dh)
EFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7e81639 <__strlen_ia32+9>:    and    edx,eax
   0xb7e8163b <__strlen_ia32+11>:   je     0xb7e81661 <__strlen_ia32+49>
   0xb7e8163d <__strlen_ia32+13>:   jp     0xb7e81656 <__strlen_ia32+38>
=> 0xb7e8163f <__strlen_ia32+15>:   cmp    BYTE PTR [eax],dh
   0xb7e81641 <__strlen_ia32+17>:   je     0xb7e816e6 <__strlen_ia32+182>
   0xb7e81647 <__strlen_ia32+23>:   inc    eax
   0xb7e81648 <__strlen_ia32+24>:   cmp    BYTE PTR [eax],dh
   0xb7e8164a <__strlen_ia32+26>:   je     0xb7e816e6 <__strlen_ia32+182>
[------------------------------------stack-------------------------------------]
0000| 0xbfffec0c --> 0xb7e338d2 (<_IO_vfprintf_internal+8322>:  add    esp,0x10)
0004| 0xbfffec10 ("ABAA\022\362\377\277\001")
0008| 0xbfffec14 --> 0xbffff212 ("%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA")
0012| 0xbfffec18 --> 0x1 
0016| 0xbfffec1c --> 0x34 ('4')
0020| 0xbfffec20 --> 0x1d5c0c 
0024| 0xbfffec24 --> 0x0 
0028| 0xbfffec28 --> 0x200034 ('4')
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
__strlen_ia32 () at ../sysdeps/i386/i586/strlen.S:51
51  ../sysdeps/i386/i586/strlen.S: File o directory non esistente.

I was able to exploit the program but I cannot understand the reason for this error. Thanks

Luigi
  • 21
  • 4

1 Answers1

0

Does your exploit string (shellcode) contain any % characters? You're passing it to printf as a format string.

If it's the 0xbffff212 ("%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA") that shows up in your disassembly, then notice that it starts with %s. The first thing it does is looks for a 2nd arg and treat it as a char*, which it apparently passes to strlen.

Since your main only passed one arg to printf, there's just whatever garbage is on the stack, which isn't a valid pointer to a 0-terminated string, so printf segfaults.

i.e. your target program also has a format-string vulnernability, and you're exploiting it with a denial-of-service attack before main returns. :P


Use printf("%s", buf); or fprintf(buf, stdout) to print arbitrary strings.

Or use puts(buf) if you don't mind appending a newline.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • opss...shame on me...you are so right!!! I was taken by the buffer overflow and not looking at that possibility. I checked the `pattern_create` result and it actually has lots of `%` characters... thanks a lot for your prompt reply! – Luigi Jan 03 '19 at 15:36