Basic Binary Protections

Just some bad notes

Binary Protections (ASLR/PIE/NX)

  • if ASLR is enabled, need to leak an address from the memory region

    • offset between addresses will not change

  • PIE (Position Independent Executable)

    • ASLR for the actual binary’s code and memory regions

  • NX (Non-Executable)

    • Stack region of the memory is not executable

    • You can determine this using vmap

      gef➤  vmmap
      Start              End                Offset             Perm Path
      0x0000000000400000 0x0000000000401000 0x0000000000000000 r-- /tmp/tryc
      0x0000000000401000 0x0000000000402000 0x0000000000001000 r-x /tmp/tryc
      0x0000000000402000 0x0000000000403000 0x0000000000002000 r-- /tmp/tryc
      0x0000000000403000 0x0000000000404000 0x0000000000002000 r-- /tmp/tryc
      0x0000000000404000 0x0000000000405000 0x0000000000003000 rw- /tmp/tryc
      0x00007ffff7dcb000 0x00007ffff7df0000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
      0x00007ffff7df0000 0x00007ffff7f63000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
      0x00007ffff7f63000 0x00007ffff7fac000 0x0000000000198000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
      0x00007ffff7fac000 0x00007ffff7faf000 0x00000000001e0000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
      0x00007ffff7faf000 0x00007ffff7fb2000 0x00000000001e3000 rw- /usr/lib/x86_64-linux-gnu/libc-2.29.so
      0x00007ffff7fb2000 0x00007ffff7fb8000 0x0000000000000000 rw-
      0x00007ffff7fce000 0x00007ffff7fd1000 0x0000000000000000 r-- [vvar]
      0x00007ffff7fd1000 0x00007ffff7fd2000 0x0000000000000000 r-x [vdso]
      0x00007ffff7fd2000 0x00007ffff7fd3000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
      0x00007ffff7fd3000 0x00007ffff7ff4000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.29.so
      0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000022000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
      0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
      0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /usr/lib/x86_64-linux-gnu/ld-2.29.so
      0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw-
      0x00007ffffffde000 0x00007ffffffff000 0x0000000000000000 rw- [stack]
      0xffffffffff600000 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
  • Stack Canary

    • Random value placed at bottom of stack frame

      • if it is overwritten, then there is memory corruption (or in this case BOF) and terminates the program

      • Typical Stack Canary check in a binary

       0x0000000000401169 <+55>:    mov    rax,QWORD PTR [rbp-0x8]
       0x000000000040116d <+59>:    xor    rax,QWORD PTR fs:0x28
       0x0000000000401176 <+68>:    je     0x40117d <main+75>
       0x0000000000401178 <+70>:    call   0x401030 <__stack_chk_fail@plt>
      • Using debugger to check the stack canary from RBP/EBP

      gef➤  x/g $rbp-0x8
      0x7fffffffdfe8:    0x92105577ff879300
      ```
      a
      Here we can see is the stack canary. We can tell that it is the stack canary from several different things. Firstly it is the value being used when it is doing the stack canary check. Also it is around the spot on the stack it should be. Also it matches the pattern of a stack canary. While they are random they do fit a general pattern.
      
      For `x64` elfs, the pattern is an `0x8` byte qword, where the first seven bytes are random and the last byte is a null byte.
      
      For `x86` elfs, the pattern is a `0x4` byte dword, where the first three bytes are random and the last byte is a null byte.
      

Last updated