Distrustful Decomposition Engineering Secure Software Last Revised: - PowerPoint PPT Presentation

Distrustful Decomposition Engineering Secure Software Last Revised: September 18, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1

Software Security Design Patterns Software security design patterns do exist ● Typically just gang-of-four patterns with adaptations for security ○ Typically not used in practice (unrealistic situations) ○ Distrustful Decomposition is a really good design pattern ● Leverages simplicity (or complexity) of operations and the level ○ of permissions needed SWEN-331: Engineering Secure Software Benjamin S Meyers 2

Key Principles Principle of least privilege ● If something requires privileges, give it the very least amount ○ Defense in depth ● Doesn’t mitigate any specific vulnerabilities, but does make ○ exploits of certain vulnerabilities less successful Use simplicity and complexity to our advantage ● Ensure risky parts of the system have “obviously no ○ vulnerabilities” Make things so simple that you know every step, can test every ○ step, and be confident that no vulnerabilities exist SWEN-331: Engineering Secure Software Benjamin S Meyers 3

Key Principles Assume an attacker gets past other defenses, how do we: ● Protect the inner parts of the system? ○ Limit the capabilities of the attacker? ○ Believe our critical subsystems are secure? ○ Note: In this lecture “process” means “executing program” ● SWEN-331: Engineering Secure Software Benjamin S Meyers 4

Permissions Challenges When programs are executed, the code has permissions (via ● executing user, setuid, setgid, etc.) Not just unix/linux; every OS has a permissions model ○ e.g. Windows pop up dialogs ○ Many programs need elevated (root) permissions to function ● Web servers: listen/respond on HTTP (port 80) ○ Email servers: listen/respond on SMTP (port 25) ○ Mobile apps: listening for text messages vs. displaying previews ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 5

Permissions Challenges What permissions are truly needed and when? ● Some programs have entirely separate functions that should ● not impact each other Browsers: each tab has has permissions that are roughly the ○ same, but need to be sandboxed so they don’t impact others Solution: design architecture around your permissions needs ● Think about permission needs early and design architecture ○ around them SWEN-331: Engineering Secure Software Benjamin S Meyers 6

Distrustful Decomposition Decompose the system into separate processes with separate ● permissions Figure out what part of your systems needs root privileges and ○ have that run in a root process i.e. fork NOT threads -- threads have shared memory ○ Processes vs. Threads ● OS knows about threads, doesn’t really interact with them ○ All threads in a single process generally have access to the same ○ memory Processes are managed by the OS ○ Processes communicate using Inter-Process Communication ○ (IPC) SWEN-331: Engineering Secure Software Benjamin S Meyers 7

Distrustful Decomposition Each process should distrust all of the others ● i.e. validate input from another process ○ i.e. re-check credentials and integrity mechanisms ○ e.g. root process listens on port 80 for data from the internet and ○ passes that off to the webserver, etc. -- the webserver should not have root privilege! Simplify the root-level subsystems to an extreme extent ● Know your code and test thoroughly ○ Make sure vulnerable code does not run as root ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 8

Distrustful Decomposition Outcomes ● Complex code gets sandboxed → reduces impact of an exploit ○ More security checks get incorporated throughout the code ○ Incorporate distrust at the architectural level ○ Note: It’s really hard to implement DD after the fact ● Tight coupling makes it hard to extract out root-level stuff ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 9

Example: Apache Webserver Apache, nginx, IIS all use Distrustful Decomposition ● Apache: install plops binaries where they need to be, creates ● user “apache” with very minimal, non-root permissions When you start Apache, only the code listening on port 80 is ● run by root Everything else (e.g. reading static files, executing PHP) is run by ○ a non-root process If an attacker were able to send a buffer overflow (it’s been ● done), DD makes sure it runs in the unprivileged code SWEN-331: Engineering Secure Software Benjamin S Meyers 10 10

Challenge: Process Memory Not Shared If your system has multiple processes (which it will in DD), ● those processes need to talk to each other Processes can’t access each other’s memory ○ Inter-Process Communication (IPC) ● SWEN-331: Engineering Secure Software Benjamin S Meyers 11 11

Simple Inter-Process Communication Techniques Files ● Simplest for most developers, but have limitations ○ Files have no structure → complex inputs, hard to validate ○ Concurrency usually not enforced in files; locking gets tough; it ○ must be respected (concurrency challenges → complexity) Files are slow: open → write → close → read ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 12 12

Simple Inter-Process Communication Techniques Signals ● Built into the OS so the OS can communicate with processes ○ Simple messaging, not for transferring data (no payload) ○ No injection possible ■ e.g. CTRL+C → SIGINT (interrupting signal) → ask process to stop ○ e.g. SIGTERM → commands a process to stop ○ e.g. SIGKILL → doesn’t ask, just kills ○ e.g. SIGSEGV → sent to OS when program writes outside of its ○ memory e.g. SIGPOLL → “poke” ○ Limited: mostly for failures, platform dependent ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 13 13

Simple Inter-Process Communication Techniques Clipboards ● User-driven IPC ○ Can set and get clipboard contents programmatically ○ Users get mad when you do this, but you see it a lot in modern web apps ■ e.g. copy GitHub repo URL to clipboard ■ Big security concern! ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 14 14

Advanced IPC Techniques Named Pipes ● FIFO buffer; OS hooks two processes together ○ Define a virtual file that one process can write to and another ○ process reads from Supported at OS level: mkfifo --mode=0640 /tmp/irc_packets ○ Super fast, but reader and writer processes have to be on the ○ same system Note: STDIN and STDOUT are unnamed pipes ○ Restricted to parent-child processes ■ Destroyed when those processes terminate ■ SWEN-331: Engineering Secure Software Benjamin S Meyers 15 15

Advanced IPC Techniques Sockets ● Programming constructs that send/receive data ○ Write to traditional networked socket via OS network interface ○ Can be set to “loop back” to the original machine if needed ○ Work locally or across the network ○ Scalable to multiple systems ○ Slow: Overhead of traveling between layers, protocols, etc. ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 16 16

Advanced IPC Techniques Sockets ● Programming constructs that send/receive data ○ Write to traditional networked socket via OS network interface ○ Can be set to “loop back” to the original machine if needed ○ Work locally or across the network ○ Scalable to multiple systems ○ Slow: Overhead of traveling between layers, protocols, etc. ○ Note: There are many more IPC strategies ● e.g. message passing, message queues, technology-specific ○ solutions (Java RMI), memory-mapped files Constantly evolving ecosystem due to security, reliability, ○ simplicity, etc. SWEN-331: Engineering Secure Software Benjamin S Meyers 17 17

Example: QMail Threat Model Root-level - SMTP listening IPC via files - Very small and simple! User-level Operations - Queue management - CLI processing Remote - Error handling Email - Configuration server - Virtual domains IPC via files, - Delivery to client - etc. Root-level - SMTP sending SIGPOLL - Very small and simple! Machine Boundary Trust Boundary Trust Boundary SWEN-331: Engineering Secure Software Benjamin S Meyers 18 18

Example: Google Chrome (sort of) Each browser tab is a separate process ● IPC primarily through files via custom IPC subsystem ○ Some OS-specific IPC mechanisms for synchronous message ○ passing Rendering processes restricted to individual tabs ○ In Firefox, tabs are separate threads ● Firefox could be faster because the OS doesn’t care about ○ threads, but a buffer overflow in one tab could corrupt others If a Chrome tab crashes or gets attacked, all other tabs are safe ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 19 19

Example: Google Chrome (sort of) Great example of decomposition, but not always distrustful ● OS-level file permissions are not employed ○ Still a lot of threads and shared memory for performance ○ Vulnerabilities can occur where direct file access results in ○ effective IPC If the browser is compromised, all tabs are vulnerable ● e.g. extension needs to load for every tab ○ e.g. settings change need to propagate to every tab ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 20 20