Outline Return address protections CSci 5271 Introduction to Computer Security Announcements intermission Day 5: Low-level defenses and counterattacks ASLR and counterattacks Stephen McCamant University of Minnesota, Computer Science & Engineering W ✟ X (DEP) Canary in the coal mine Adjacent canary idea Photo credit: Fir0002 CC-BY-SA Terminator canary Random canary Value hard to reproduce because it would tell the copy to stop Can’t reproduce because attacker can’t StackGuard: 0x00 0D 0A FF guess 0: String functions For efficiency, usually one per execution newline: ❢❣❡ts (), etc. -1: ❣❡t❝ () Ineffective if disclosed carriage return: similar to newline? Doesn’t stop: ♠❡♠❝♣② , custom loops
XOR canary Further refinements Want to protect against non-sequential More flexible to do earlier in compiler overwrites Rearrange buffers after other variables XOR return address with value ❝ at Reduce chance of non-control overwrite entry Skip canaries for functions with only XOR again with ❝ before return small variables Who has an overflow bug in an 8-byte Standard choice for ❝ : see random array? canary What’s usually not protected? Where to keep canary value Backwards overflows Fast to access Function pointers Buggy code/attacker can’t read or write Adjacent structure fields Linux/x86: ✪❣s✿✵①✶✹ Adjacent static data objects 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 the canary Announcements intermission Why not just store the return address there? ASLR and counterattacks Needs to be a separate stack W ✟ X (DEP) Ultimate return address protection Note to early readers Outline Return address protections This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make ASLR and counterattacks sure you have the latest slides for announcements W ✟ X (DEP) 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 A long sequence of chained returns, one ✵①✽✵✹✾✻✼✽✿ ❁❛❞❞r ♦❢ ♣r✐♥t❢ ✐♥ ❧✐❜❝❃ pop ✵①✽✵✹✾✻✼❝✿ ❁❛❞❞r ♦❢ s②st❡♠ ✐♥ ❧✐❜❝❃ ret2pop (M¨ uller) Outline Return address protections Announcements intermission ASLR and counterattacks W ✟ X (DEP) 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 Next time Can we do more? Oh, yes. Return-oriented programming (ROP) Classic academic approach: what’s the And counter-defenses most we could ask for? Control-flow integrity (CFI) Here: “Turing completeness” How to do it: reading for Thursday
Recommend
More recommend
