Preview question Which of these defense techniques would completely prevent a ROP attack from returning from an intended CSci 5271 return instruction to an unintended gadget? Introduction to Computer Security A. ASLR Day 6: Low-level defenses and counterattacks, part 2 B. A non-executable stack Stephen McCamant C. Adjacent stack canaries University of Minnesota, Computer Science & Engineering D. A shadow stack E. A and C, but only if used together Outline Basic idea W ✟ X (DEP) Traditional shellcode must go in a memory area that Defenses in HA1 is Return-oriented programming (ROP) writable, so the shellcode can be inserted executable, so the shellcode can be executed Announcements But benign code usually does not need this BCECHO combination Control-flow integrity (CFI) W xor X, really ✿ ✭ ❲ ❫ ❳ ✮ More modern exploit techniques Non-writable code, ❳ ✦ ✿ ❲ Non-executable data, ❲ ✦ ✿ ❳ Prohibit execution of static data, stack, heap E.g., read-only .text section Not a problem for most programs Has been standard for a while, especially on Unix Incompatible with some GCC features no one uses Lets OS efficiently share code with multiple program Non-executable stack opt-in on Linux, but now instances near-universal Implementing ❲ ✟ ❳ One important exception Page protection implemented by CPU Remaining important use of self-modifying code: Some architectures (e.g. SPARC) long supported ❲ ✟ ❳ just-in-time (JIT) compilers x86 historically did not E.g., all modern JavaScript engines One bit controls both read and execute Allow code to re-enable execution per-block Partial stop-gap “code segment limit” ♠♣r♦t❡❝t , ❱✐rt✉❛❧Pr♦t❡❝t Eventual obvious solution: add new bit Now a favorite target of attackers NX (AMD), XD (Intel), XN (ARM)
Counterattack: code reuse Classic return-to-libc (1997) Overwrite stack with copies of: Attacker can’t execute new code Pointer to libc’s s②st❡♠ function So, take advantage of instructions already in binary Pointer to ✧✴❜✐♥✴s❤✧ string (also in libc) There are usually a lot of them The s②st❡♠ function is especially convenient And no need to obey original structure Distinctive feature: return to entry point Chained return-to-libc Beyond return-to-libc Shellcode often wants a sequence of actions, e.g. Can we do more? Oh, yes. Restore privileges Classic academic approach: what’s the most we Allow execution of memory area could ask for? Overwrite system file, etc. Can put multiple fake frames on the stack Here: “Turing completeness” Basic idea present in 1997, further refinements First reading for today Outline BCMTA Makefile W ✟ X (DEP) Defenses in HA1 Return-oriented programming (ROP) ❈❋▲❆●❙ ✿❂ ✲❣ ✲❲❛❧❧ ✲♠✸✷ ❭ ✲❢♥♦✲st❛❝❦✲♣r♦t❡❝t♦r ❭ Announcements ✲③ ❡①❡❝st❛❝❦ ✲③ ♥♦r❡❧r♦ BCECHO Control-flow integrity (CFI) More modern exploit techniques BCMTA Makefile BCMTA Makefile ❈❋▲❆●❙ ✿❂ ✲❣ ✲❲❛❧❧ ✲♠✸✷ ❭ ❈❋▲❆●❙ ✿❂ ✲❣ ✲❲❛❧❧ ✲♠✸✷ ❭ ✲❢♥♦✲st❛❝❦✲♣r♦t❡❝t♦r ❭ ✲❢♥♦✲st❛❝❦✲♣r♦t❡❝t♦r ❭ ✲③ ❡①❡❝st❛❝❦ ✲③ ♥♦r❡❧r♦ ✲③ ❡①❡❝st❛❝❦ ✲③ ♥♦r❡❧r♦ Standard non-security options Turn off canaries
BCMTA Makefile BCMTA Makefile ❈❋▲❆●❙ ✿❂ ✲❣ ✲❲❛❧❧ ✲♠✸✷ ❭ ❈❋▲❆●❙ ✿❂ ✲❣ ✲❲❛❧❧ ✲♠✸✷ ❭ ✲❢♥♦✲st❛❝❦✲♣r♦t❡❝t♦r ❭ ✲❢♥♦✲st❛❝❦✲♣r♦t❡❝t♦r ❭ ✲③ ❡①❡❝st❛❝❦ ✲③ ♥♦r❡❧r♦ ✲③ ❡①❡❝st❛❝❦ ✲③ ♥♦r❡❧r♦ Allow execution on stack Leave GOT writable More HA1 VM unprotection More HA1 VM unprotection Not in Makefile: disable ASLR Not in Makefile: disable /bin/sh privilege dropping Is done system-wide in VM Linux shells differ in whether they’ll run setuid For non-VM testing, can use s❡t❛r❝❤ ✐✸✽✻ ✲❘ Recompiled ❞❛s❤ with security check removed Outline Basic new idea W ✟ X (DEP) Defenses in HA1 Treat the stack like a new instruction set Return-oriented programming (ROP) “Opcodes” are pointers to existing code Announcements Generalizes return-to-libc with more programmability BCECHO Control-flow integrity (CFI) More modern exploit techniques ret2pop (M¨ uller) ret2pop (M¨ uller) Take advantage of shellcode pointer already present on stack Rewrite intervening stack to treat the shellcode pointer like a return address A long sequence of chained returns, one pop
Gadgets Another partial example Basic code unit in ROP Any existing instruction sequence that ends in a return Found by (possibly automated) search Overlapping x86 instructions Where gadgets come from push %esi Possibilities: mov $0x56,%dh sbb $0xff,%al inc %eax or %al,%dh movzbl 0x1c(%esi),%edx incl 0x8(%eax) ... Entirely intended instructions 0f b6 56 1c ff 40 08 c6 Entirely unaligned bytes Fall through from unaligned to intended Standard x86 return is only one byte, 0xc3 Variable length instructions can start at any byte Usually only one intended stream Building instructions Hardest case: conditional branch String together gadgets into manageable units of Existing jCC instructions not useful functionality But carry flag CF is Examples: Three steps: Loads and stores 1. Do operation that sets CF Arithmetic 2. Transfer CF to general-purpose register Unconditional jumps 3. Add variable amount to ✪❡s♣ Must work around limitations of available gadgets Further advances in ROP Anti-ROP: lightweight Can also use other indirect jumps, overlapping not Check stack sanity in critical functions required Check hardware-maintained log of recent indirect Automation in gadget finding and compilers jumps (kBouncer) In practice: minimal ROP code to allow transfer to Unfortunately, exploitable gaps other shellcode
Gaps in lightweight anti-ROP Anti-ROP: still research Three papers presented at 2014’s USENIX Security Modify binary to break gadgets Hide / flush jump history Fine-grained code randomization Very long loop ✦ context switch Beware of adaptive attackers (“JIT-ROP”) Long “non-gadget” fragment Next up: control-flow integrity (Later: call-preceded gadgets) Outline StackGuard question W ✟ X (DEP) What two methods are mentioned in the StackGuard Defenses in HA1 paper to prevent canary forgery? Return-oriented programming (ROP) A. “terminator canary” and “random canary” Announcements B. “StackGhost” and “random XOR canary” BCECHO C. “stack layout randomization” and “entropy canary” Control-flow integrity (CFI) D. “StackGhost” and “PointGuard” E. “Keccak” and “Rijndael” More modern exploit techniques Exercise set 1 BCMTA vulnerability found! Due Wednesday 11:59pm The ✲❞ option and a recipient starting with t❡st enabled a backdoor One member of each group submits a PDF via Canvas Caused message body to be sent directly to a shell Outline BCECHO code W ✟ X (DEP) ✈♦✐❞ ♣r✐♥t❴❛r❣✭❝❤❛r ✯str✮ ④ ❝❤❛r ❜✉❢❬✷✵❪❀ ✐♥t ❧❡♥❀ Defenses in HA1 ✐♥t ❜✉❢❴s③ ❂ ✭s✐③❡♦❢✭❜✉❢✮✲s✐③❡♦❢✭◆❯▲▲✮✮ Return-oriented programming (ROP) ✯ s✐③❡♦❢✭❝❤❛r ✯✮❀ ❧❡♥ ❂ str❧❝♣②✭❜✉❢✱ str✱ ❜✉❢❴s③✮❀ Announcements ✐❢ ✭❧❡♥ ❃ ❜✉❢❴s③✮ ④ BCECHO ❢♣r✐♥t❢✭st❞❡rr✱✧❚r✉❝❛t✐♦♥ ♦❝❝✉r❡❞ ✧ ✧✇❤❡♥ ♣r✐♥t✐♥❣ ✪s❭♥✧✱ str✮❀ Control-flow integrity (CFI) ⑥ ❢✇r✐t❡✭❜✉❢✱ s✐③❡♦❢✭❝❤❛r✮✱ ❧❡♥✱ st❞♦✉t✮❀ More modern exploit techniques ⑥
Attack planning Overwriting the return address Looks like candidate for classic stack-smash Where to put the attack value? Via disassembly inspection Via GDB Via experimentation Outline Some philosophy W ✟ X (DEP) Defenses in HA1 Remember whitelist vs. blacklist? Return-oriented programming (ROP) Rather than specific attacks, tighten behavior Announcements Compare: type system; garbage collector vs. use-after-free BCECHO CFI: apply to control-flow attacks Control-flow integrity (CFI) More modern exploit techniques Basic CFI principle Approximating the call graph Each indirect jump should only go to a One set: all legal indirect targets programmer-intended (or compiler-intended) target Two sets: indirect calls and return points I.e., enforce call graph ♥ sets: needs possibly-difficult points-to analysis Often: identify disjoint target sets Target checking: classic Target checking: classic Identifier is a unique 32-bit value ❝♠♣ ❬❡❝①❪✱ ✶✷✸✹✺✻✼✽❤ Can embed in effectively-nop instruction ❥♥❡ ❡rr♦r❴❧❛❜❡❧ Check value at target before jump ❧❡❛ ❡❝①✱ ❬❡❝①✰✹❪ ❥♠♣ ❡❝① Optionally add shadow stack
Recommend
More recommend
