Preview question What is the return type of tr ? CSci 5271 A. - PDF document

Preview question What is the return type of ❣❡t❝❤❛r✭✮ ? CSci 5271 A. s✐❣♥❡❞ ❝❤❛r Introduction to Computer Security B. ✐♥t Defensive programming and design C. ✉♥s✐❣♥❡❞ ❝❤❛r Stephen McCamant D. ❝❤❛r University of Minnesota, Computer Science & Engineering E. ❢❧♦❛t Outline Basic CFI principle Control-flow integrity (CFI), cont’d More modern exploit techniques Each indirect jump should only go to a Saltzer & Schroeder’s principles programmer-intended (or compiler-intended) target Announcements + BCECHO intermission I.e., enforce call graph More secure design principles Often: identify disjoint target sets Software engineering for security Secure use of the OS 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 ❥♠♣ ❡❝① Challenge 1: performance Challenge 2: compatibility In CCS’05 paper: 16% avg., 45% max. Compilation information required Widely varying by program Probably too much for on-by-default Must transform entire program together Improved in later research Can’t inter-operate with untransformed code Common alternative: use tables of legal targets

Recent advances: COTS COTS techniques Commercial off-the-shelf binaries CCFIR: use Windows ASLR information to find targets CCFIR (Berkeley+PKU, Oakland’13): Windows Linux paper: keep copy of original binary, build CFI for COTS Binaries (Stony Brook, USENIX’13): translation table Linux Control-Flow Guard Coarse-grained counter-attack “Out of Control” paper, Oakland’14 CFI-style defense now in latest Windows systems Limit to gadgets allowed by coarse policy Compiler generates tables of legal targets Indirect call to function entry Return to point after call site (“call-preceded”) At runtime, table managed by kernel, read-only to user-space Use existing direct calls to ❱✐rt✉❛❧Pr♦t❡❝t Also used against kBouncer Control-flow bending counter-attack Outline Control-flow integrity (CFI), cont’d More modern exploit techniques Control-flow attacks that still respect the CFG Saltzer & Schroeder’s principles Especially easy without a shadow stack Announcements + BCECHO intermission Printf-oriented programming generalizes More secure design principles format-string attacks Software engineering for security Secure use of the OS Target #1: web browsers Heap spraying How to take advantage of uncontrolled jump? Widely used on desktop and mobile platforms Maximize proportion of memory that is a target Easily exposed to malicious code Generalize NOP sled idea, using benign allocator JavaScript is useful for constructing fancy attacks Under W ✟ X, can’t be code directly

JIT spraying JIT spray example Can we use a JIT compiler to make our sleds? ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Exploit unaligned execution: ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Benign but weird high-level code (bitwise ops. with ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① constants) Benign but predictable JITted code ✷✺ ✾✵ ✾✵ ✾✵ ✸❝ ❛♥❞ ✩✵①✸❝✾✵✾✵✾✵✱✪❡❛① Becomes sled + exploit when entered unaligned JIT spray example Use-after-free ✾✵ ♥♦♣ ✾✵ ♥♦♣ Low-level memory error of choice in web browsers ✾✵ ♥♦♣ Not as easily audited as buffer overflows ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ Can lurk in attacker-controlled corner cases ✾✵ ♥♦♣ JavaScript and Document Object Model (DOM) ✾✵ ♥♦♣ ✾✵ ♥♦♣ ✸❝ ✷✺ ❝♠♣ ✩✵①✷✺✱✪❛❧ Sandboxes and escape Chained bugs in Pwnium 1 Google-run contest for complete Chrome exploits Chrome NaCl: run untrusted native code with SFI First edition in spring 2012 Extra instruction-level checks somewhat like CFI Winner 1: 6 vulnerabilities Each web page rendered in own, less-trusted Winner 2: 14 bugs and “missed hardening process But not easy to make sandboxes secure opportunities” While allowing functionality Each got $60k, bugs promptly fixed Outline Economy of mechanism Control-flow integrity (CFI), cont’d More modern exploit techniques Security mechanisms should be as simple as Saltzer & Schroeder’s principles possible Announcements + BCECHO intermission Good for all software, but security software needs More secure design principles special scrutiny Software engineering for security Secure use of the OS

Fail-safe defaults Complete mediation When in doubt, don’t give permission Every mode of access must be checked Whitelist, don’t blacklist Not just regular accesses: startup, maintenance, etc. Checks cannot be bypassed Obvious reason: if you must fail, fail safe E.g., web app must validate on server, not just client More subtle reason: incentives Open design Open design: strong version Security must not depend on the design being “The design should not be secret” secret If the design is fixed, keeping it secret can’t help If anything is secret, a minimal key attackers Design is hard to keep secret anyway But an unscrutinized design is less likely to be Key must be easily changeable if revealed secure Design cannot be easily changed Separation of privilege Least privilege Real world: two-person principle Programs and users should have the most limited Direct implementation: separation of duty set of powers needed to do their job Multiple mechanisms can help if they are both Presupposes that privileges are suitably divisible required Contrast: Unix r♦♦t Password and ✇❤❡❡❧ group in Unix Least privilege: privilege separation Least common mechanism Minimize the code that all users must depend on for Programs must also be divisible to avoid excess security privilege Related term: minimize the Trusted Computing Base Classic example: multi-process OpenSSH server (TCB) N.B.: Separation of privilege ✻ ❂ privilege separation E.g.: prefer library to system call; microkernel OS

Psychological acceptability Sometimes: work factor Cost of circumvention should match attacker and A system must be easy to use, if users are to apply resource protected it correctly E.g., length of password Make the system’s model similar to the user’s But, many attacks are easy when you know the bug mental model to minimize mistakes Sometimes: compromise recording Outline Control-flow integrity (CFI), cont’d More modern exploit techniques Recording a security failure can be almost as good Saltzer & Schroeder’s principles as preventing it Announcements + BCECHO intermission But, few things in software can’t be erased by r♦♦t More secure design principles Software engineering for security Secure use of the OS ROP defense question Project meetings Which of these defense techniques would completely prevent a ROP attack from returning from an intended return instruction to an unintended gadget? Starting tomorrow, run through next Wednesday A. ASLR Invitations sent yesterday B. A non-executable stack C. Adjacent stack canaries D. A shadow stack E. A and C, but only if used together Deadlines reminder Alternative Saltzer & Schroeder Not a replacement for reading the real thing, but: Exercise set 1: tonight night ❤tt♣✿✴✴❡♠❡r❣❡♥t❝❤❛♦s✳❝♦♠✴t❤❡✲s❡❝✉r✐t②✲♣r✐♥❝✐♣❧❡s✲♦❢✲s❛❧t③❡r✲❛♥❞✲s❝❤r♦❡❞❡r HA1 week 2: Friday night Security Principles of Saltzer and Schroeder, illustrated with scenes from Star Wars (Adam Shostack)

More BCECHO attacker techniques Shellcode concept Modifying a system file ❢❞ ❂ ♦♣❡♥✭✧✴❡t❝✴♣❛ss✇❞✧✱ ♥ 0-free shellcoding ❖❴❲❘❖◆▲❨⑤❖❴❆PP❊◆❉✮❀ Shellcode in an environment variable ✇r✐t❡✭❢❞✱ ✧♣✇♥❡❞❭♥✧✱ ✻✮❀ Outline Back to the preview question Control-flow integrity (CFI), cont’d More modern exploit techniques Asked before: what’s the type of the return value of Saltzer & Schroeder’s principles ❣❡t❝❤❛r ? Announcements + BCECHO intermission Why? More secure design principles Software engineering for security Secure use of the OS Separate the control plane Defense in depth Keep metadata and code separate from untrusted Multiple levels of protection can be better than one data Especially if none is perfect Bad: format string vulnerability But, many weak security mechanisms don’t add up Bad: old telephone systems Canonicalize names Fail-safe / fail-stop If something goes wrong, behave in a way that’s safe Use unique representations of objects Often better to stop execution than continue in E.g. in paths, remove ✳ , ✳✳ , extra slashes, symlinks corrupted state E.g., use IP address instead of DNS name E.g., better segfault than code injection