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

▶
distrustful decomposition
SMART_READER_LITE
LIVE PREVIEW

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

Mar 28, 2023 8 likes •242 views

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

slide-1
SLIDE 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Distrustful Decomposition

Engineering Secure Software

Last Revised: September 18, 2020 1

slide-2
SLIDE 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

  • f permissions needed

2

slide-3
SLIDE 3

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

3

slide-4
SLIDE 4

SWEN-331: Engineering Secure Software Benjamin S Meyers

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”

4

slide-5
SLIDE 5

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

5

slide-6
SLIDE 6

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

6

slide-7
SLIDE 7

SWEN-331: Engineering Secure Software Benjamin S Meyers

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)

7

slide-8
SLIDE 8

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

8

slide-9
SLIDE 9

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

9

slide-10
SLIDE 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

10 10

slide-11
SLIDE 11

SWEN-331: Engineering Secure Software Benjamin S Meyers

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)

11 11

slide-12
SLIDE 12

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

12 12

slide-13
SLIDE 13

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

13 13

slide-14
SLIDE 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

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!

14 14

slide-15
SLIDE 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

15 15

slide-16
SLIDE 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

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.

16 16

slide-17
SLIDE 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

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.

17 17

slide-18
SLIDE 18

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: QMail Threat Model

18 18

User-level Operations

  • Queue management
  • CLI processing
  • Error handling
  • Configuration
  • Virtual domains
  • Delivery to client
  • etc.

Root-level

  • SMTP listening
  • Very small and

simple! Root-level

  • SMTP sending
  • Very small and

simple! Remote Email server IPC via files IPC via files, SIGPOLL Trust Boundary Trust Boundary Machine Boundary

slide-19
SLIDE 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

19 19

slide-20
SLIDE 20

SWEN-331: Engineering Secure Software Benjamin S Meyers

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

20 20

slide-21
SLIDE 21

SWEN-331: Engineering Secure Software Benjamin S Meyers

StageFright: DD Gone Wrong

  • 2015 Android vulnerability

○ Buffer overflow in video transcoding function that produces preview thumbnail in text messages ○ Send a crafted video to a phone → arbitrary code execution ○ Previews generated automatically; no user intervention

  • Process listening to text messages requires root privilege

○ Process generating thumbnails also ran as root! ○ Arbitrary code execution as root → cover your tracks

21 21

slide-22
SLIDE 22

SWEN-331: Engineering Secure Software Benjamin S Meyers

StageFright: DD Gone Wrong

  • Researchers discovered and reported vulnerability to

Google

○ Fixed in a few days, but when Google tried to push the update to phone carriers, they dragged their feet ○ Went unpatched for six months

  • Takeaway: separate complex, non-root functionality from

simple, root functionality → use Distrustful Decomposition!

22 22

slide-23
SLIDE 23

SWEN-331: Engineering Secure Software Benjamin S Meyers

Design & Project Implications

  • Do not procrastinate Distrustful Decomposition

○ Easier to build upon than bolt on

■ Usually requires understanding of OS, which most languages shelter you from (e.g. Java vs. C/C++)

○ Introduces distrust at key points in the system ○ Introduces necessary complexity into the system

  • IPC abstracted into a subsystem is often the next step

○ Requires input validation and output normalization/sanitization ○ Requires defining communication protocols ○ Conway’s Law: structure of your team is dependent on the design of your system (and vice versa)

23 23