8

Working through the Modern Binary Exploitation course from RPI here. I'm having trouble with an example on exploiting ASLR which is supposed to use a memory leak to gain information about the stack to then calculate the offset for a system call. Here's the code: 

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

/* gcc -pie -fPIE -fno-stack-protector -o aslr_leak2 ./aslr_leak2.c */

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

char leaky[16];

if(argc < 2)
{
    printf("Please provide two arguments.\n");
    return 1;
}

memcpy(leaky, argv[1], 16);

printf("Leaky buffer: %s\n", leaky);
printf("another round? : ");
fgets(leaky, 64, stdin);

return 0;
}

Doesn't look like a format string exploit to get the memory leak, so I'm not sure how it's supposed to work. If I'm understanding correctly, I should get some information from the first print which helps me to overwrite the return pointer to create a ROP gadget from. Yes, I can run this inside of GDB if I wanted to, but I want to be able to not do that.

David
  • 15,814
  • 3
  • 48
  • 73
Praet
  • 101
  • 1
  • 5

1 Answers1

1

Providing 16 chars as first argument, you'll fill up the leaky buffer. As there is no space for a terminating null, the subsequent printf will echo your 16 characters and will continue to print whatever is on the stack until it encounters a terminating null character. This is your info leak. Addresses of ROP gadgets can then be calculated relative to your leaked address/es.

Dennis Sanders
  • 21
  • 2
  • Ok. I think I figured out what I'm looking for. I just wasn't understanding what I'm reading. I can see in GDB that the buffer ends at the location of another libc function which should allow me to chain together other rop commands. Don't think I totally understand why the libc call is what's next on the stack since it was already called earlier in the function. It isn't returned to at any point. And it's libc_csu_init that's on the stack. – Praet Aug 15 '17 at 23:21