Stack Canaries, Bounds Checking, NX, DEP, ROP, ASLR(week 3)

Question 1

canaries

Answer 1

help program to detect if it has been attacked before the attacker takes control

Question 2

idea of canary

Answer 2

what if the compiler could add a piece of data between buffer and control data

that way if there is an overflow, the compiler will first check to make sure that the canary is not overwritten

Question 3

what if an attacker knows the canary?

Answer 3

a few defenses:

1. canary could be copy-unfriendly “terminator” characters
   - -> “\0\CR\LF-1”
   - -> strcpy will stop copying at \0 and won’t copy the rest of the canary
2. canary randomly generated on each run
   - -> doesn’t work if adversary can read its value somehow (like format string vulnerabilities)
3. random canary XORed with control data
   - -> store: “return address XOR saved ebp XOR random canary”
   - -> a little harder for attacker but still bypassable

Question 4

are attacks possible without harming the canary?

Answer 4

yes. we could just overwrite local variables and completely avoid the canary

Question 5

Explain Option 1 for bounds checking: electric fences

Answer 5

• only useful for the heap
• allocate memory page
• then, allocate a memory page above it (at a higher address) that serves as the electric fence
• we call mprotect on this page and it makes the page has no access privileges
• if we try to access the electric fences then the program will crash

good performance: no cost, all done by hardware (unless BO)
downside: doesn’t work with the stack, only works at the granularity of pages, can’t do push and pop, when stack shrinks data isn’t deleted

INEFFICIENT IN TERMS OF SPACE, minimum page size is usually around 4 KB

they are found in a lot of debugging software like valgrind

Question 6

describe option 2 for bounds checking: fat pointers

Answer 6

existing pointers: 32 bit address
fat pointer: [32 bit start address][32 bit end address][32 bit ptr address]

drawbacks:
• fat pointers are big. they make everything big.
• legacy code doesn’t understand fat pointers
• updates are non-atomic because fat pointers use 3 words
–>makes multithreaded code harder to write

Question 7

what’s a low-fat pointer

Answer 7

use part of 64 bit address to encode something about the length of the pointer (invented at penn)

Question 8

explain non-executable bit (NX)

Answer 8

make the stack non-executable

memory pages have 3 permission bits
R: Read
W: Write
X: Execute

Idea: set the NX bit on the memory pages that make up the stack

make memory W XOR X

Either memory is writable (stack) or executable (like the code pages), but not both

Question 9

who sets the NX bit?

Answer 9

• compiler annotates memory section in the ELP binary

• -ELF contains headers of section in memory
• -Can set section header flags (sh_flags) to:
• —SHF_WRITE: makes section’s memory writable
• —SHF_EXECINSTR: allows section’s memory to contain executable instr.

• loader reads these annotations and sets the NX bit (kernel)
–if a region of memory doesn’t have the SHF_EXECINSTR flag, the loader sets the NX bit on the memory pages

Question 10

Who checks the NX bit?

Answer 10

the MMU!

lives in CPU. checks page permissions. the MMU takes memory address and figures out if the command is consistent with the permissions of the page.

Question 11

drawbacks NX bit/DEP

Answer 11

• prevents benign code rewriting at runtime (useful for JTI compiling)
  
  • there are ways to get around this

• attacker cannot inject code but can still overflow and change return address and point it to existing code (libraries and program’s own code)

Question 12

Return Oriented Programming

Answer 12

helps attackers bypass data execution prevention

DEP prevents us from running injected code but we can use code that is already there

Question 12

options for bypassing DEP

Answer 12

1: get lucky, see if exact sequences of opcodes exists in program’s code

2. return to libc: we can use libc see if linked in application,
   
   • find out their address
   • setup the stack before returning to them

ROP:

3. recycle existing instructions
   
   • use opcodes from different functions (“gadgets”) and string them together to get the sequence we want
   • ROP

Question 13

how to spot gadgets for ROP?

Answer 13

• look for ret instruction and then work backwards (0xc3)
• useful gadget pop, push, or modify common registers
• we have automated tools that can do this now

Question 14

Address Space Randomization Layout

Answer 14

attacks rely on attacker knowing the exact layout of memory address of injected shellcode, libraries, or gadgets

• randomizes the start address of the stack, heap, program code, libs, and data on each run of program
• if program crashes and restarts, it should have different address space
• it attacker has a copy of binary, address space on their machine is different than address space on target’s machine

Question 15

true/false

with ASLR address space sections are still contiguous

Answer 15

true (we just shift start address of stack by some random offset)

Question 16

important to remember for compiling when using ASLR

Answer 16

libraries compiled with fPIC (position independent code)

program compiled with -pie (position independent executable)

Question 17

in linux, ASLR randomizes:

Answer 17

stack: at some random place close to the top
executable: random place close to the bottom (if not PIE, not at all!)
heap: random offset from executable (if randomized_va_space = 2)
shared libraries: random virtual address (mmap_base) between heap and stack

Question 18

who performs ASLR?

Answer 18

compiler ensures program does not rely on absolute addresses
addressing is relative to program counter (eip)
in some cases absolute addresses still needed

loader (kernel) randomizes address space when process starts

dynamic linker resolves needed absolute addresses at runtime
procedure linkage table (PLT)
global offset table (GOT)

Question 19

ways to bypass ASLR

Answer 19

if application is not compiled with PIE/PIC
can build ROP gadgets that use executable’s code

if application forks() a new process to handle client request
fork() doesn’t randomize address space
can find out where things are (use execv instead)

if application is vulnerable to format strings can learn address space

if not compiled with DEP
can use NOP slide or Heap spray attacks