Engineering Secure Software Key Principles Principle of Least privilege Defense in Depth Obviously No Vulnerabilities vs No Obvious ie Assume they get past that other defenses how do we ID: 684160
Download Presentation The PPT/PDF document "Distrustful Decomposition" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Distrustful Decomposition
Engineering Secure SoftwareSlide2
Key Principles
Principle of Least privilege
Defense in Depth
Obviously No Vulnerabilities
(vs. No Obvious)i.e. Assume they get past that 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” == “executing program”
©2015 Andrew MeneelySlide3
Permissions Challenges
When programs are executed, the code has permissions
(via executing user,
setuid
, setgid, etc.)Many programs need elevated (root) permissions to functionWeb servers: listen & respond on HTTP, e.g. port 80Email servers: listen & respond on SMTP, e.g. port 25Mobile apps: listening for text messages vs. displaying previewsWhat permissions are truly needed, and when?Some programs have entirely separate functions that should not impact each other
Browsers: one web page should not impact the others
Solution: design your
architecture around your permissions needsSlide4
Distrustful Decomposition
Decompose the system into separate processes with separate permissions
i.e.
fork()
NOT threads. Threads still have shared memory.Communicate via inter-process communication (see next slides)Each process distrusts the otheri.e. validate the input from the other processi.e. re-check credentials and integrity mechanismsSimplify the root-level subsystems to an extreme extent
Outcomes
Complex code gets
sandboxed r
educe impact of an exploit
More security checks get incorporated throughout the code
Incorporate distrust at the architecture levelSlide5
Inter-Process Communication: Simple Techniques
Files
Simplest for most
developers, but…
Files have no structure to them complexity in inputs!Locking gets tough. It must be respected(concurrency challenges complexity!!)SignalsSimple messaging, not for transferring data
Pre-defined by OS (Unix has ~30 of these)
e.g. SIGINT, SIGTERM, SIGKILL, SIGSEGV, SIGPOLL
Clipboard
Can set and get clipboard programmatically
Users don’t like you messing with this…
…but you see it increasingly used in Web apps todaySlide6
IPC: Advanced Techniques
Named pipes
a.k.a. a FIFO buffer
Define a “virtual file” that one process can write to and another process reads from
Supported at the OS (file system) level$ mkfifo --mode=0640 /tmp/
irc_packets
BTW:
stdin
and
stdout
are part of using unnamed pipes
!
Pro: fast
!!
Con: on the same system
Sockets
Write to a traditional networked socket via the OS network interfaceSockets can be set to “loop back” to the original machine if neededPro: scalable to multiple systems! Con: slowerMANY more IPC strategies: message passing, message queues, technology-specific solutions (e.g. Java RMI), memory-mapped filesConstantly evolving ecosystem due to security, reliability, simplicity, etc.Slide7
e.g. QMail
Remote email server
Root-level
SMTP sending
VERY SMALL & SIMPLE
User-level operations
Queue management
CLI processing
Error handling
Configuration
Virtual domains
Delivery to client
etc.
Trust & Machine boundaries
Trust boundary
IPC via files, SIGPOLL
Root-level
SMTP listening
VERY SMALL & SIMPLE
IPC via filesSlide8
e.g. Sorta DD: Google Chrome
Each browser tab is a separate process
IPC is accomplished primarily through files via their own IPC subsystem
Some IPC OS-specific mechanisms for synchronous message passing
Restrict rendering processes to their individual tabsBUT! Not exactly “Distrustful”OS-level file permissions are not employedStill a lot of threads and shared memory for performanceVulnerabilities can occur where direct file access results in effective IPCSlide9
e.g. Gone Wrong: Stage Fright
Stage Fright Android Vulnerability of 2015
Buffer overflow in video transcoding function that produces a preview thumbnail on Android text messages
Send a crafted video to a phone
arbitrary code executionNo user intervention required (i.e. previews are automatically generated)BUT! Process listening to text messages requires root privsProcess for producing thumbnails
also ran as root
Arbitrary code execution as root
cover your tracks
Lesson:
Separate complex, non-root functionality
Avoid buffer overflows, of course.Slide10
Design & Project Implications
Distrustful Decomposition is not something you want to
procrastinate
Easier to build upon than bolt on
Introduces distrust at key points in the systemIntroduces necessary complexity into your systemIPC abstracted into a subsystem is often the next step after DDRequires input validation and output normalization/sanitizationRequires defining the communication protocolsConway’s Law may even help: separate duties among developers along process lines