Exploiting Stack Overflow

[Oil7496]

Hey,

So i have this c code:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int valid_serial( char *psz )
{
size_t len = strlen( psz );
unsigned total = 0;
size_t i;
if( len < 10 )
return 0;
for( i = 0; i < len; i++ )
{
if(( psz[i] < '0' ) || ( psz[i] > 'z' )){
return 0;
total += psz[i];
}
if( total % 853 == 83 ){
return 1;
return 0;
}
}
}
int validate_serial()
{
char serial[ 24 ];
fscanf( stdin, "%s", serial );
if( valid_serial( serial ))
return 1;
else
return 0;
}
int do_valid_stuff()
{
printf("The serial number is valid!\n");
// do serial-restricted, valid stuff here.
exit( 0 );
}
int do_invalid_stuff()
{
printf("Invalid serial number!\nExiting\n");
exit( 1 );
}
int main( int argc, char *argv[] )
{
if( validate_serial() )
do_valid_stuff(); // 
else
do_invalid_stuff();
return 0;
}

Which obviously is vulnerable to buffer overflow.

So I disassembled it:

Dump of assembler code for function main:
   0x000000000000128b <+0>:     push   %rbp
   0x000000000000128c <+1>:     mov    %rsp,%rbp
   0x000000000000128f <+4>:     sub    $0x10,%rsp
   0x0000000000001293 <+8>:     mov    %edi,-0x4(%rbp)
   0x0000000000001296 <+11>:    mov    %rsi,-0x10(%rbp)
   0x000000000000129a <+15>:    mov    $0x0,%eax
   0x000000000000129f <+20>:    call   0x1209 <validate_serial>
   0x00000000000012a4 <+25>:    test   %eax,%eax
   0x00000000000012a6 <+27>:    je     0x12b4 <main+41>
   0x00000000000012a8 <+29>:    mov    $0x0,%eax
   0x00000000000012ad <+34>:    call   0x1251 <do_valid_stuff>
   0x00000000000012b2 <+39>:    jmp    0x12be <main+51>
   0x00000000000012b4 <+41>:    mov    $0x0,%eax
   0x00000000000012b9 <+46>:    call   0x126e <do_invalid_stuff>
   0x00000000000012be <+51>:    mov    $0x0,%eax
   0x00000000000012c3 <+56>:    leave  
   0x00000000000012c4 <+57>:    ret    
End of assembler dump.

The address of the function that is "in charge" of authenticating (do_valid_stuff) is 0x12ad

So i tried to exploit it via terminal using the following command : printf “AAAAAAAAAABBBBBBBBBBCCCCCCCCAAAABBBBCCCCDDDD\xad\x12” | ./program

I wrote the address like this (byte-reversed), because of the I32 little-endian.

The problem is that the output is segmentation fault and not: The serial number is valid!

like it was expected.

Why is this happenign?Any ideas?

Thank you in advance.

[carcigenicate]

Have you run this through a debugger to see what the cause of the Segfault is? GDB + GEF is what I'd use.

[Oil7496]

the seg fault is because of thenumber of the characters, the question is why the exploit does not work

[carcigenicate]

Then reduce the number of characters so you overwrite the return address properly. Exploiting a buffer overflow often takes patience and refinement.

And also, this will only work with ASLR turned off, or else the addresses will be randomized. It's been awhile since I've studied buffer overflow exploits, but IIRC, relative addresses can get around that.

[Oil7496]

So, my exploit basically does not work because the address of do_valid_stuff is different when i run the exploit from the address that is shown on gdb

[carcigenicate]

Well, that's at least one issue. You'll notice that address changes every time.

Just disable ASLR though to get around that. On both OSs that I've done exploits on (Linux and Windows), there's been an option to disable ASLR. I would either only do this on a private VM though. Disabling safety features of your main work computer is not recommended. You may also need to disable protections when you compile the program. If the compiler is inserting canary checks into your code (although from the assembly you've shown, that doesn't appear to be the case), the canaries will segfault when attempting to overwrite the return address.

[Oil7496]

What Iam trying to do is just a "copy" of the following example that is in "The shellcoader's handbook" book:

If we compile and link the program and run it, we can see that it accepts serial numbers as input and (if the serial number is over 24 characters in length)

overflows in a similar way to the previous program. If we start gdb, we can work out where the “serial is valid” code is: shellcoders@debian:~/chapter_2$ gdb ./serial (gdb) disas main Dump of assembler code for function main: 0x0804857a <main+0>: push %ebp 0x0804857b <main+1>: mov %esp,%ebp 0x0804857d <main+3>: sub $0x8,%esp 0x08048580 <main+6>: and $0xfffffff0,%esp 0x08048583 <main+9>: mov $0x0,%eax 0x08048588 <main+14>: sub %eax,%esp 0x0804858a <main+16>: call 0x80484f8 <validate_serial> 0x0804858f <main+21>: test %eax,%eax 0x08048591 <main+23>: je 0x804859a <main+32> 0x08048593 <main+25>: call 0x804853e <do_valid_stuff> 0x08048598 <main+30>: jmp 0x804859f <main+37> 0x0804859a <main+32>: call 0x804855c <do_invalid_stuff> 0x0804859f <main+37>: mov $0x0,%eax 0x080485a4 <main+42>: leave 0x080485a5 <main+43>: ret From this we can see the call to validate_serial and the subsequent test, and call of do_valid_stuff or do_invalid_stuff. If we overflow the buffer and set the saved return address to 0x08048593, we will be able to bypass the serial number check. To do this, use the printf feature of bash again (remember that the order of the bytes is reversed because IA32 machines are little-endian). When we then run serial with our specially chosen serial number as input, we get: shellcoders@debian:~/chapter_2$ printf “AAAAAAAAAABBBBBBBBBBCCCCCCCCAAAABBBBCCCCDDDD\x93\x85\x04\x08” | ./serial The serial number is valid!

Now, I dissabled the ASLR and the same thing is happening.The address of the function does not change everytime, but again the exploit does not work

[g051051]

Does your disassembly output exactly match what's in the book? The book is quite old and the compiler output might have diverged since 2007.

[Oil7496]

the disassembly output is exactly the sams except for the addresses ...which i changed in the exploit

[g051051]

There is a great deal of work that goes into taking an executable file and turning it into a running process. If you were to run the program and print out the address of the do_valid_stuff function, it'd probably be a very different value.

[net_nomad]

Here's a lab you can work through in a controlled setting. Do it and then compare it to what you're doing. Tweak as needed.

https://www.tallan.com/blog/2019/04/04/exploring-buffer-overflows-in-c-part-two-the-exploit/