Theo de Raadt: Mitigations and Other Real Security Features

1. Theo de Raadt: Mitigations and Other Real Security
Features
Largely invisible security improvements
Slides
This talk explain the why instead of what, behind security mitigation mechanisms
Software will never be perfect
● logic bug cascades, often externally controllable
● attackers can do illegal access + control of code in program & libs, toy with kernel surface
● attacker knowledge and methods are improving fast
● current tools and practices are insufficient
● thus mitigations
Mitigations
● inexpensive tweaks, increase difficulty of performing attacks
● pressures software to be robust
Robust (adj.)
● (def) does not break down, recovers quickly, not wholly affected
● Theo strongly disagree with that definition
○ error-recovery is an unsound practice, detection mechanisms don’t exist
● if memory has been overwritten, how does one continue?
● fail-closed
Justifying Fail-Closed
● user becomes aware of bug (painful but preferable to only attacker knowing)
● “detects-and-terminates” execution before control-flow creates further mess and less useful bug report
● user files bug reports
● programmer fixes bug
=> best current practice for building software
We fix bugs only after we learn of them
17 years of mitigation work
(word cloud of mitigation techniques, completed and not)
● cause “weird” operations to fail-closed (i.e. crash immediately)
Features of mitigations
● reduce effectiveness of some attack method
● low overhead
● easy to understand
● easy to apply to old and new code
● one mitigation doesn’t need to fix all problems
● expose bugs earlier - improve triage
Components attackers use
● knowledge
○ bugs
○ location of objects (absolute and relative locations)
○ gadgets, constants, pointers, register values
● mechanisms
○ ROP
○ code reuse
○ syscalls
● act upon objects
○ filesystem
○ fd

2. ○ leftovers on stack
Knowledge: API, ABI and beneath
● Details of ABI and implementation sneak upwards, providing attackers with data to use during attack
● details left on stack and in registers, long enough for attackers to use
ABI + implementation leakage
● { int i; void *p = &i;}
If this code crashes, can find return address based upon the register p is stored in.
details well-known, de-facto standardized and exposed.
Knowledge: stack, register leaks
● attackers run same binaries as you, in same environment
○ ROP operates on these
● with a crash, attacker know regs and stack values
● just need a way to pivot to control
Attacker Tooling: ROP
● hijack instruction sequences using false return frames
● gadget: small seq of reg memory transfers above a true function ret instruction
● attackers needs to know location of gadgets, addr of stack
● other methods: JOP, SROP etc
Even Scarier: BROP (Blind ROP)
● addr space oracle
● repeated probes against reused addr-space learns enough to perform minimum ROP operations
● can discover (and bypass) some mitigations
● see paper for details
Stack protector example
● attacker needs to know:
○ location of stack
○ ordering of stack objs
○ call frame ordering (in-args, savepc, savefp, locals)
● stack protector only disrupts the simplest attack methods
ASLR effect?
● attacker needs to know:
○ abs integer values
○ rel addr (offsets)
○ abs addr (pointers)
○ to 3 places: code, data, stack
● ASLR increases difficulty of attack
Costs - time for discussion
● Not all mitigations will be cost free
● Processors have gotten faster
○ e.g. Intel improving instruction scheduling before function return
● What percentage of performance would you willingly spend on security?
● Most mitigations are reimplementing of an existing mechanism, just more strictly
Shared library improvements
● progressive improvements - old GOT & PLTs were writable!
● secure PLT
● no more relocs
● RELRO
● kbind()
○ only kernel can modify PLT
● DT_BIND_NOW
○ can even unmap ld.so if no more dynamic bindings are required
(Took 30 years to add layers of strictness to basic dynamic linking idea)
Malloc hardening
● OpenBSD malloc hardened in 20+ ways

3. ● randomness, object rotation, metadata protection, double free & use-after-free detection, heap overflow
detection
● half of hardening features enabled by default
Pledge: POSIX subsets
● No subtle behavior changes
● No error returns
● fails-closed
● illegal operations crash
● easy to learn
How does pledge help?
● 2nd spec by programmers, directly in the program
● no behavior changes, only used to detect violations
● 2nd spec also useful to programmers as debug tool
Privilege Separation + Pledge
● Pledge enforces the separation
Common ideas behind mitigation
● reduce discoverable knowledge
● improve historical weakness of permission models
● disrupt non standard control flows
● education of privilege separation during program design
● reduce syscall availability during execution
Mitigations change details not specified in standards
● harm current attack methods and help us debug code
Resistance against mitigations
● some await language/compiler advances to save us
○ e.g. control flow integrity in hardware and software
● some prefer long-term binary compatibility over security
● some business models require ignoring security
● “X-will-save -us” -> “X-fail-to-compile perl”- > ...
● NIH syndrome
Limiting choice is related to safety
(photo of traffic jam at intersection in Vietnam)
(slowing down is a way to achieve safety)
Safety systems innovations are crucial
● old solutions may not match modern needs
● don’t get tied down by back compat
● innovation crucial
● don’t sleep on shoulders of giants
Q&A
● Could hardware manufacturers help? (e.g. CFI) A: would be great but haven’t seen anything that’d
really work.
○ Always wanted an instruction that stores random values in registers or memory really cheaply.
For stopping info leaks.
○ Mark cache as “may not be read unless written to before”
○ ROP gadgets create reads and writes to memory as artifacts, could detect these and stop them
Postel’s maxim is dangerous
● IETF: draft-thomson-postel-was-wrong-02.txt
● similar problem with ABI + below, which benefits attackers
● POSIX standard is too liberal
● POSIX implementations are full of historical standard behaviours which attackers rely upon