Outline Return address protections ASLR and counterattacks CSci - PDF document

Outline Return address protections ASLR and counterattacks CSci 5271 Introduction to Computer Security W ✟ X (DEP) Low-level defenses and counterattacks Announcements (combined lecture) Return-oriented programming (ROP) Stephen McCamant University of Minnesota, Computer Science & Engineering Control-flow integrity (CFI) More modern exploit techniques Complex anti-canary attack Complex anti-canary attack Canary not updated on ❢♦r❦ in server Canary not updated on ❢♦r❦ in server Attacker controls number of bytes Attacker controls number of bytes overwritten overwritten ANRY BNRY CNRY DNRY ENRY FNRY search ✷ ✸✷ ✦ search ✹ ✁ ✷ ✽ Shadow return stack Outline Return address protections Suppose you have a safe place to store ASLR and counterattacks the canary W ✟ X (DEP) Why not just store the return address Announcements there? Return-oriented programming (ROP) Needs to be a separate stack Control-flow integrity (CFI) Ultimate return address protection More modern exploit techniques

Basic idea Code and data locations Execution of code depends on memory “Address Space Layout Randomization” location Move memory areas around randomly E.g., on 32-bit x86: so attackers can’t predict addresses Direct jumps are relative Keep internal structure unchanged Function pointers are absolute E.g., whole stack moves together Data must be absolute Relocation (Windows) PIC/PIE (GNU/Linux) Extension of technique already used in “Position-Independent Code / compilation Executable” Keep table of absolute addresses, Keep code unchanged, use register to instructions on how to update point to data area Disadvantage: code modifications take Disadvantage: code complexity, register time on load, prevent sharing pressure hurt performance What’s not covered Entropy limitations Intuitively, entropy measures amount of randomness, in bits Main executable (Linux 32-bit PIC) Random 32-bit int: 32 bits of entropy Incompatible DLLs (Windows) ASLR page aligned, so at most Relative locations within a module/area ✸✷ ✲ ✶✷ ❂ ✷✵ bits of entropy Other constraints further reduce possibilities

Leakage limitations GOT hijack (M¨ uller) Main program fixed, libc randomized If an attacker learns the randomized PLT in main program used to call libc base address, can reconstruct other locations Rewire PLT to call attacker’s favorite libc functions Any stack address ✦ stack unprotected, etc. E.g., turn ♣r✐♥t❢ into s②st❡♠ GOT hijack (M¨ uller) ret2pop (M¨ uller) ♣r✐♥t❢❅♣❧t✿ ❥♠♣ ✯✵①✽✵✹✾✻✼✽ Take advantage of shellcode pointer ✳✳✳ already present on stack s②st❡♠❅♣❧t✿ ❥♠♣ ✯✵①✽✵✹✾✻✼❝ Rewrite intervening stack to treat the ✳✳✳ shellcode pointer like a return address ✵①✽✵✹✾✻✼✽✿ ❁❛❞❞r ♦❢ ♣r✐♥t❢ ✐♥ ❧✐❜❝❃ A long sequence of chained returns, one pop ✵①✽✵✹✾✻✼❝✿ ❁❛❞❞r ♦❢ s②st❡♠ ✐♥ ❧✐❜❝❃ ret2pop (M¨ uller) Outline Return address protections ASLR and counterattacks W ✟ X (DEP) Announcements Return-oriented programming (ROP) Control-flow integrity (CFI) More modern exploit techniques

Basic idea Non-writable code, ❳ ✦ ✿ ❲ Traditional shellcode must go in a memory area that is E.g., read-only .text section writable, so the shellcode can be inserted Has been standard for a while, executable, so the shellcode can be especially on Unix executed But benign code usually does not need Lets OS efficiently share code with this combination multiple program instances W xor X, really ✿ ✭ ❲ ❫ ❳ ✮ Non-executable data, ❲ ✦ ✿ ❳ Implementing ❲ ✟ ❳ Page protection implemented by CPU Prohibit execution of static data, stack, Some architectures (e.g. SPARC) long heap supported ❲ ✟ ❳ Not a problem for most programs x86 historically did not Incompatible with some GCC features no One bit controls both read and execute one uses Partial stop-gap “code segment limit” Non-executable stack opt-in on Linux, but Eventual obvious solution: add new bit now near-universal NX (AMD), XD (Intel), XN (ARM) One important exception Counterattack: code reuse Remaining important use of Attacker can’t execute new code self-modifying code: just-in-time (JIT) compilers So, take advantage of instructions E.g., all modern JavaScript engines already in binary Allow code to re-enable execution There are usually a lot of them per-block And no need to obey original structure ♠♣r♦t❡❝t , ❱✐rt✉❛❧Pr♦t❡❝t Now a favorite target of attackers

Classic return-to-libc (1997) Chained return-to-libc Shellcode often wants a sequence of Overwrite stack with copies of: actions, e.g. Pointer to libc’s s②st❡♠ function Restore privileges Pointer to ✧✴❜✐♥✴s❤✧ string (also in libc) Allow execution of memory area Overwrite system file, etc. The s②st❡♠ function is especially Can put multiple fake frames on the convenient stack Distinctive feature: return to entry point Basic idea present in 1997, further refinements Beyond return-to-libc Outline Return address protections ASLR and counterattacks Can we do more? Oh, yes. W ✟ X (DEP) Classic academic approach: what’s the most we could ask for? Announcements Here: “Turing completeness” Return-oriented programming (ROP) How to do it: next Control-flow integrity (CFI) More modern exploit techniques Note to early readers First project meetings Sent invitations yesterday, for meetings This is the section of the slides most through next Monday likely to change in the final version Will see most of you later this week If class has already happened, make sure you have the latest slides for First progress reports due Monday announcements 2/25

Exercise set 1 Outline Return address protections ASLR and counterattacks Due tomorrow by 11:59pm W ✟ X (DEP) One member of each group should Announcements submit PDF or plain text via Canvas Return-oriented programming (ROP) Control-flow integrity (CFI) More modern exploit techniques Basic new idea ret2pop (M¨ uller) Treat the stack like a new instruction Take advantage of shellcode pointer set already present on stack “Opcodes” are pointers to existing Rewrite intervening stack to treat the code shellcode pointer like a return address Generalizes return-to-libc with more A long sequence of chained returns, one pop programmability ret2pop (M¨ uller) Gadgets Basic code unit in ROP Any existing instruction sequence that ends in a return Found by (possibly automated) search

Another partial example Overlapping x86 instructions push %esi mov $0x56,%dh sbb $0xff,%al inc %eax or %al,%dh movzbl 0x1c(%esi),%edx incl 0x8(%eax) ... 0f b6 56 1c ff 40 08 c6 Variable length instructions can start at any byte Usually only one intended stream Where gadgets come from Building instructions String together gadgets into Possibilities: manageable units of functionality Entirely intended instructions Examples: Entirely unaligned bytes Loads and stores Fall through from unaligned to intended Arithmetic Standard x86 return is only one byte, Unconditional jumps 0xc3 Must work around limitations of available gadgets Hardest case: conditional branch Further advances in ROP Can also use other indirect jumps, Existing jCC instructions not useful overlapping not required But carry flag CF is Automation in gadget finding and Three steps: compilers 1. Do operation that sets CF 2. Transfer CF to general-purpose register In practice: minimal ROP code to allow 3. Add variable amount to ✪❡s♣ transfer to other shellcode

Anti-ROP: lightweight Gaps in lightweight anti-ROP Three papers presented at 2014’s Check stack sanity in critical functions USENIX Security Check hardware-maintained log of Hide / flush jump history recent indirect jumps (kBouncer) Very long loop ✦ context switch Unfortunately, exploitable gaps Long “non-gadget” fragment (Later: call-preceded gadgets) Anti-ROP: still research Outline Return address protections ASLR and counterattacks Modify binary to break gadgets W ✟ X (DEP) Fine-grained code randomization Beware of adaptive attackers Announcements (“JIT-ROP”) Return-oriented programming (ROP) Next up: control-flow integrity Control-flow integrity (CFI) More modern exploit techniques Some philosophy Basic CFI principle Remember whitelist vs. blacklist? Each indirect jump should only go to a Rather than specific attacks, tighten programmer-intended (or behavior compiler-intended) target Compare: type system; garbage collector I.e., enforce call graph vs. use-after-free Often: identify disjoint target sets CFI: apply to control-flow attacks