Defence in Depth Petr Ročkai Defence in Depth 2/44 November 20, 2018 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/44 November 20, 2018 Part 1: Layered Security Defence in Depth 4/44 November 20, 2018 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/44 November 20, 2018 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/44 November 20, 2018 Layered Security • secure each component / layer separately • many fences: make life hard for the attacker • log all suspicious failures in your programs 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 − how many holes the attacker punched in your defence Defence in Depth 7/44 November 20, 2018 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 8/44 November 20, 2018 Layering Example • your run a C program & it was reviewed for security • but a tricky buffer over low slipped past • the attacker discovers the over low • they attempt an exploit, but you use stack guard • the program crashes, alerting the sysadmin • the system goes into lockdown • the buffer over low is identi ied and ixed • you win Defence in Depth 9/44 November 20, 2018 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 10/44 November 20, 2018 Part 2: Code Review & Open Design Defence in Depth 11/44 November 20, 2018 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 12/44 November 20, 2018 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 13/44 November 20, 2018 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 14/44 November 20, 2018 Insecurity by Obscurity • rarely, if ever, independently reviewed • the only interested party is the attacker • often riddled with basic laws and inadequate crypto • attackers are often good at reverse engineering − disassemblers, debuggers and emulators − decompilers and automated control low analysis • insider attacks are a thing Defence in Depth 15/44 November 20, 2018 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 & found vulnerable) • car remotes (Keelog, VW, …) • ~ every copy protection / DRM scheme ever Defence in Depth 16/44 November 20, 2018 Obscurity Bene its • 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 17/44 November 20, 2018 Compromise: Open Design • you may have reasons to avoid opening your source • you can still document and open the design • this allows bene icial independent review Defence in Depth 18/44 November 20, 2018 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 19/44 November 20, 2018 Part 3: Mitigation Techniques Defence in Depth 20/44 November 20, 2018 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 21/44 November 20, 2018 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 22/44 November 20, 2018 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 23/44 November 20, 2018 Isolation: Motivation • stop propagation of faults • protect unrelated applications • make attacks harder to conduct Defence in Depth 24/44 November 20, 2018 Isolation: Approaches • separate processes • separate user accounts • lightweight containers (freebsd jails, linux lxc) • virtual machines • physical separation Defence in Depth 25/44 November 20, 2018 Sandboxing • further restrict dangerous code • SELinux, AppArmor (Linux) • pledge (OpenBSD), capsicum (FreeBSD) • Chromium content processes (also Edge, also Safari) • ZeroVM Defence in Depth 26/44 November 20, 2018 Isolation Failures • hyper-threading (SMT) side channels (CVE-2005-0109) • rowhammer (CVE-2015-0565) • MMUsidechannelattack(defeatsASLR,CVE-2017-5925) Isolation: Not Applicable • how do you protect the database from wordpress? • bookmarks, cookies or history from the browser? Defence in Depth 27/44 November 20, 2018 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 28/44 November 20, 2018 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 29/44 November 20, 2018 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 30/44 November 20, 2018 Compare: if ( check_access() == EDENIED ) die( "access denied" ); with if ( check_access() != OK ) die( "access denied" ); Whathappensifcheck_access() returnsENOMEM? Defence in Depth 31/44 November 20, 2018 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 32/44 November 20, 2018 Part 4: Dropping & Separating Privileges Defence in Depth 33/44 November 20, 2018 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 34/44 November 20, 2018 Dropping Privileges • how to get rid of excessive privilege? • use dedicated, restricted user accounts • chroot jailing to restrict ile system access • sandboxing (selinux, pledge, …) Defence in Depth 35/44 November 20, 2018 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 ilesystem with chroot Defence in Depth 36/44 November 20, 2018 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 • suf iciently sandboxed code is not part of the TCB Defence in Depth 37/44 November 20, 2018 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 38/44 November 20, 2018 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 39/44 November 20, 2018 Other Examples • mail software: qmail, post ix • OpenBSD relayd, httpd, bgpd, ntpd, … • chromium (see also sandboxing) Defence in Depth 40/44 November 20, 2018 Part 5: Related Issues Defence in Depth 41/44 November 20, 2018 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 42/44 November 20, 2018 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 43/44 November 20, 2018 Security Patterns • like software design patterns (Gang of Four) • commonly used designs and techniques • recommended as good design by multiple sources http://www.munawarhafiz.com/securitypatterncatalog/index.php Defence in Depth 44/44 November 20, 2018 Summary • never assume your code is perfect • every defence could (and will) fail • always stack multiple approaches • be prepared for the worst case Questions?