November 25, 2019 Defence in Depth Petr Ročkai Defence in Depth 2/45 November 25, 2019 Overview • Part 1: Layered Security • Part 2: Code Review & Open Design • Part 3: Mitigation Techniques • Part 4: Dropping and Separating Privileges • Part 5: Related Issues Defence in Depth 3/45 November 25, 2019 Part 1: Layered Security Defence in Depth 4/45 November 25, 2019 Goal: Secure Systems • no privilege or access violations • no leaks of private data • no unauthorised resource abuse • availability of service Solution: Write Bulletproof Code • never works in practice • but see also seL4 Defence in Depth 5/45 November 25, 2019 Alternative Solution • write good, even if imperfect, code • keep it simple • use established components / libraries • code reviews (both security and correctness) • mitigation techniques (ASLR, Stack Guard, ...) • least privilege & privilege separation • minimise inter-component trust Defence in Depth 6/45 November 25, 2019 Layered Security • secure each component / layer separately • many fences: make life hard for the attacker • log all suspicious failures in your programs Defence in Depth 7/45 November 25, 2019 Rules • if you detect an attack early, you win ∘ before anything of value is stolen or compromised ∘ if the attacker gives up you also win • if you win, it doesn’t matter how exactly ∘ even if the attacker punched holes in your defence Defence in Depth 8/45 November 25, 2019 Why Many Layers • each layer slows the attacker down • each layer has a chance to detect and report the attack • the attacker may fail to penetrate further at any point • obstacles → frustration → mistakes • more attacker mistakes = better chance that you win Defence in Depth 9/45 November 25, 2019 Layering Example • your run a C program & it was reviewed for security • but a tricky buffer overflow slipped past • the attacker discovers the overflow • they attempt an exploit, but you use stack guard • the program crashes, alerting the sysadmin • the system goes into lockdown • the buffer overflow is identified and fixed • you win Defence in Depth 10/45 November 25, 2019 Single Points of Failure • certain SPOFs are unavoidable • prime example: the user • common failure modes can be mitigated • bad passwords × 2FA • social engineering × least privilege & strict protocols • bad mitigation: password policies Defence in Depth 11/45 November 25, 2019 Part 2: Code Review & Open Design Defence in Depth 12/45 November 25, 2019 Code Review • the practice of reading and understanding code • done by yourself, your team-mates, an external audit • catches the most egregious security violations • not a foolproof method • the law of diminishing returns applies Defence in Depth 13/45 November 25, 2019 Code Review: Open Source • with enough eyeballs, all bugs are shallow • sounds nice, but is not true • counterexamples: heartbleed, shellshock, ... • still very helpful Defence in Depth 14/45 November 25, 2019 Security by Obscurity • the polar opposite of open source • keep the design secret • might use proprietary encryption • keep the source code secret • obfuscate binaries &c. Does Not Work Defence in Depth 15/45 November 25, 2019 Insecurity by Obscurity • rarely, if ever, independently reviewed • the only interested party is the attacker • often riddled with basic flaws and inadequate crypto • attackers are often good at reverse engineering ∘ disassemblers, debuggers and emulators ∘ decompilers and automated control flow analysis • insider attacks are a thing Defence in Depth 16/45 November 25, 2019 Insecurity by Obscurity: Famous Examples • GSM encryption (A5/1) ∘ also an example of intentionally weakened crypto ∘ and a practical downgrade attack • MS Wireless Keyboard (XOR the MAC, CVE-2010-1184) • MIFARE Classic (reverse engineered & broken) • car remotes (Keelog, VW, ...) • ~ every copy protection / DRM scheme ever Defence in Depth 17/45 November 25, 2019 Obscurity Benefits • obscurity could also work in your favour • think non-updateable software in tamper-proof boxes • hire expert programmers & reviewers • stick with established crypto • contract a few security labs for external review Defence in Depth 18/45 November 25, 2019 Compromise: Open Design • you may have reasons to avoid opening your source • you can still document and open the design • this allows beneficial independent review Defence in Depth 19/45 November 25, 2019 Use Established Modules • use standard, tested and widely deployed components ∘ especially for cryptography • use standard protocols, formats &c. • they had a lot more review than your code • never implement your own cryptography ∘ implementation bugs are common ∘ especially side channels ∘ sources of randomness are a serious problem Defence in Depth 20/45 November 25, 2019 Part 3: Mitigation Techniques Defence in Depth 21/45 November 25, 2019 Mitigation • assumption: bugs are inevitable • idea: make them hard or impossible to exploit • not a substitute for good code • part of a layered security approach Defence in Depth 22/45 November 25, 2019 Mitigation Approaches • make common bugs harder to exploit • isolate components from each other • principle of least privilege • keep each component simple • fail securely whenever possible Defence in Depth 23/45 November 25, 2019 Exploit Mitigations • W^X – write XOR execute • address space layout randomisation • boot-time library randomised relinking • trap sleds (as opposed to nop sleds) • guard pages • malloc & mmap randomisation • secure randomness by default Defence in Depth 24/45 November 25, 2019 Isolation: Motivation • stop propagation of faults • protect unrelated applications • make attacks harder to conduct Defence in Depth 25/45 November 25, 2019 Isolation: Approaches • separate processes • separate user accounts • lightweight containers (freebsd jails, linux lxc) • virtual machines • physical separation Defence in Depth 26/45 November 25, 2019 Sandboxing • further restrict dangerous code • SELinux, AppArmor (Linux) • pledge (OpenBSD), capsicum (FreeBSD) • Chromium content processes (also Edge, also Safari) • ZeroVM Defence in Depth 27/45 November 25, 2019 Isolation Failures • hyper-threading (SMT) side channels (CVE-2005-0109) • rowhammer (CVE-2015-0565) • MMU side channel (defeats ASLR, CVE-2017-5925) Isolation: Not Applicable • how do you protect the database from wordpress? • bookmarks, cookies or history from the browser? Defence in Depth 28/45 November 25, 2019 Simplicity • complex code often has more bugs • simpler code means fewer bugs • applies to design as well • keep the code clean and readable • avoid clever hacks and dubious optimisation • resist adding unnecessary features Defence in Depth 29/45 November 25, 2019 Minimise Trust • trust is the opposite of isolation • servers should not trust clients & vice versa • never trust your inputs (see previous lectures) • do not trust the network • never run unsigned code • faults propagate along trusted channels Defence in Depth 30/45 November 25, 2019 Fail Safe vs Fail Secure • behaviour during failure is often very important • fail safe: do not endanger lives or property • fail secure: ensure security is not broken • not an either-or choice • but not completely orthogonal either Defence in Depth 31/45 November 25, 2019 Compare: if ( check_access() == EDENIED ) die( "access denied" ); with if ( check_access() != OK ) die( "access denied" ); What happens if check_access() returns ENOMEM? Defence in Depth 32/45 November 25, 2019 Errors are Hard to Test • error paths often contain vulnerabilities • often inadequately tested • use automated tools (fuzzing, static analysis) Errors are Info Leaks • stack traces, database details • the padding oracle attack Defence in Depth 33/45 November 25, 2019 Part 4: Dropping & Separating Privileges Defence in Depth 34/45 November 25, 2019 Principle of Least Privilege • give only privilege required to get the job done • applies to both programs and users • does not prevent security holes • this is again a mitigation technique • Saltzer & Schröder 1975 Defence in Depth 35/45 November 25, 2019 Dropping Privileges • how to get rid of excessive privilege? • use dedicated, restricted user accounts • chroot jailing to restrict file system access • sandboxing (selinux, pledge, ...) Defence in Depth 36/45 November 25, 2019 Privilege Drop: Common Example • opening ports below 1024 requires root • so does reading SSL private keys • nothing much else in httpd does, though • after startup, drop to an unprivileged user • maybe also lock out filesystem with chroot Defence in Depth 37/45 November 25, 2019 Trusted Computing Base • the entirety of code important for security • includes most application software • capable of violating user’s security constraints • should be as small as possible • usually very large in practice • sufficiently sandboxed code is not part of the TCB Defence in Depth 38/45 November 25, 2019 Privilege Separation • multiple processes • separate responsibilities • simple & robust inter-process protocol • more powerful than the least privilege approach • capable of removing code from the TCB Defence in Depth 39/45 November 25, 2019 OpenSSH • all network code runs in a separate process • under a special user & chrooted • privileged process is well isolated • the latter decides everything security-relevant Defence in Depth 40/45 November 25, 2019 Other Examples • mail software: qmail, postfix • OpenBSD relayd, httpd, bgpd, ntpd, ... • chromium (see also sandboxing) Defence in Depth 41/45 November 25, 2019 Part 5: Related Issues Defence in Depth 42/45 November 25, 2019 Programming Languages • not all languages are equal from security POV • C is among the worst options • C++ is better if used correctly • Java is better yet (memory safe) • yet safer languages exist (Rust, Haskell, ...) Defence in Depth 43/45 November 25, 2019 Keep Yourself Informed • what is the security record of the components you use? • learn from your mistakes • or even better, from mistakes of others • learn about the latest trends • read security blogs, papers, ... Defence in Depth 44/45 November 25, 2019 Security Patterns • like software design patterns (Gang of Four) • commonly used designs and techniques • recommended as good design by multiple sources • www.munawarhafiz.com/securitypatterncatalog Defence in Depth 45/45 November 25, 2019 Summary • never assume your code is perfect • every defence could (and will) fail • always stack multiple approaches • be prepared for the worst case Questions?