6

I am working on return oriented programming exploitation on a x86_64 Linux. However, my research leads to impossibility of ROP exploitation in 64-bit Linux machine because all of code segments are loaded in null byte leading addresses. Is it true?

Gdb,Sections:
(gdb) i file
    `/home/******/Desktop/BOF/lib64', file type elf64-x86-64.
    Entry point: 0x400ffc
    0x0000000000400190 - 0x00000000004001b0 is .note.ABI-tag
    0x00000000004001b0 - 0x00000000004001d4 is .note.gnu.build-id
    0x00000000004001d8 - 0x00000000004002f8 is .rela.plt
    0x00000000004002f8 - 0x0000000000400312 is .init
    0x0000000000400320 - 0x00000000004003e0 is .plt
    0x00000000004003e0 - 0x0000000000494808 is .text
    0x0000000000494810 - 0x000000000049614c is __libc_freeres_fn
    0x0000000000496150 - 0x00000000004961f8 is __libc_thread_freeres_fn
    0x00000000004961f8 - 0x0000000000496201 is .fini
    0x0000000000496220 - 0x00000000004b6224 is .rodata
    0x00000000004b6228 - 0x00000000004b6230 is __libc_atexit
    0x00000000004b6230 - 0x00000000004b6288 is __libc_subfreeres
    0x00000000004b6288 - 0x00000000004b6290 is __libc_thread_subfreeres
    0x00000000004b6290 - 0x00000000004c32ac is .eh_frame
    0x00000000004c32ac - 0x00000000004c33b9 is .gcc_except_table
    0x00000000006c3ea0 - 0x00000000006c3ec0 is .tdata
    0x00000000006c3ec0 - 0x00000000006c3ef8 is .tbss
    0x00000000006c3ec0 - 0x00000000006c3ed0 is .init_array
    0x00000000006c3ed0 - 0x00000000006c3ee0 is .fini_array
    0x00000000006c3ee0 - 0x00000000006c3ee8 is .jcr
    0x00000000006c3f00 - 0x00000000006c3ff0 is .data.rel.ro
    0x00000000006c3ff0 - 0x00000000006c4000 is .got
    0x00000000006c4000 - 0x00000000006c4078 is .got.plt
    0x00000000006c4080 - 0x00000000006c56f0 is .data
    0x00000000006c5700 - 0x00000000006c8308 is .bss
    0x00000000006c8308 - 0x00000000006c8338 is __libc_freeres_ptrs

    0x0000000000400190 - 0x00000000004001b0 is .note.ABI-tag
    0x00000000004001b0 - 0x00000000004001d4 is .note.gnu.build-id
    0x00000000004001d8 - 0x00000000004002f8 is .rela.plt
    0x00000000004002f8 - 0x0000000000400312 is .init
    0x0000000000400320 - 0x00000000004003e0 is .plt
    0x00000000004003e0 - 0x0000000000494808 is .text
    0x0000000000494810 - 0x000000000049614c is __libc_freeres_fn
    0x0000000000496150 - 0x00000000004961f8 is __libc_thread_freeres_fn
    0x00000000004961f8 - 0x0000000000496201 is .fini
    0x0000000000496220 - 0x00000000004b6224 is .rodata
    0x00000000004b6228 - 0x00000000004b6230 is __libc_atexit
    0x00000000004b6230 - 0x00000000004b6288 is __libc_subfreeres
    0x00000000004b6288 - 0x00000000004b6290 is __libc_thread_subfreeres
    0x00000000004b6290 - 0x00000000004c32ac is .eh_frame
    0x00000000004c32ac - 0x00000000004c33b9 is .gcc_except_table
    0x00000000006c3ea0 - 0x00000000006c3ec0 is .tdata
    0x00000000006c3ec0 - 0x00000000006c3ef8 is .tbss
    0x00000000006c3ec0 - 0x00000000006c3ed0 is .init_array
    0x00000000006c3ed0 - 0x00000000006c3ee0 is .fini_array
    0x00000000006c3ee0 - 0x00000000006c3ee8 is .jcr
    0x00000000006c3f00 - 0x00000000006c3ff0 is .data.rel.ro
    0x00000000006c3ff0 - 0x00000000006c4000 is .got
    0x00000000006c4000 - 0x00000000006c4078 is .got.plt
    0x00000000006c4080 - 0x00000000006c56f0 is .data
    0x00000000006c5700 - 0x00000000006c8308 is .bss
    0x00000000006c8308 - 0x00000000006c8338 is __libc_freeres_ptrs
  • It depends on the bug you're exploiting. You're talking about simple strcpy/strcat/sprintf/... bugs, right? – joxeankoret Feb 20 '14 at 8:56
  • Yes,but what is the difference? in all of bugs(if it is non pie) we have addresses like above...please see also : v0ids3curity.blogspot.de/2013/07/… (i cant understand how we can use rop gadgets that contains null bytes in their addresses) – user40387 Feb 20 '14 at 9:15
  • You can build ROP gadgets with null bytes in the addresses. Yes. Indeed, it's been a while I don't need to filter out 0x00 characters in my exploit payloads because it's been a while since I don't exploit a pure string manipulation problem (i.e., only binary formats and stuff). – joxeankoret Feb 21 '14 at 8:47
6

This comes down to the type of bug you are exploiting. If your payload cant contain null bytes (a vulnerable strcpy), this can become an issue, however not all bugs have this constraint. Take for example a bug in how a filetype is parsed, which allows null bytes.

Also there is the possibility of a series of bugs to be used, for example, the idea of heap spraying. Generally you spray the heap doing other "legitimate" things, such as in this write up by corelancoder. His shell code, which would be your ROP chain, is part bitmap files that he consecutively loads to "spray the heap", while the bug is actually triggered by javascript and doesn't actually contain the shellcode.

If you want to just work on ROP, and not worry about byte limitations, i'd suggest writing a simple harness to test your shellcode.

EDIT Sorry wrong harness. This one is clearly 64-bit specific.

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

int data[10000000];

void start_rop(char * rop)
{
        __asm("mov (%rax),%rsp"); //move contents of first argument into the stack pointer
}

int main(int argc, char * argv)
{

        char  code[] = "AAAAAAAA";
        char * malloc_code = (char *)malloc(sizeof(code));
        memcpy(malloc_code,&code,sizeof(code));

        start_rop(malloc_code);

        free(malloc_code);
        return 0;
}
| improve this answer | |
  • I think the above code isnt related to rop.Its just a C stub function for testing shellcodes also it can not be used for new kernels because data sections is not executable anymore. – user40387 Feb 20 '14 at 17:23
  • You are completely correct, I copied over the wrong harness. Fixed in answer. – jbh Feb 20 '14 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.