6/2/2015eurosys2006page 1 reducing tcb complexity for security-sensitive applications: three case...
Post on 18-Dec-2015
216 views
TRANSCRIPT
04/18/23EuroSys2006Page 1
Reducing TCB Complexity for Security-Sensitive Applications: Three Case Studies
Lenin Singaravelu, Calton Pu, Hermann Härtig, Christian Helmuth Georgia Tech T.U. Dresden
04/18/23EuroSys2006Page 2
Overview
• Problem Statement• AppCores• Case Studies• Evaluation & Lessons Learned• Related Work• Future Directions
04/18/23EuroSys2006Page 3
Problem
“The future of digital systems is complexity, and complexity is the worst enemy of security.” Bruce Schneier, Crypto-Gram Newsletter, March 2000
Problem
04/18/23EuroSys2006Page 4
Why is complexity a problem?
• Greater software complexity implies more software errors– Software complexity metrics such as LOC,
Cyclomatic Complexity, Henry & Kafura’s Information Flow exhibit positive correlation with software errors [Shepperd93].
• Large multipurpose applications– Unavoidable in many cases
• Large system services, libraries and kernels– Exacerbated by bad design/misconfiguration
Problem
04/18/23EuroSys2006Page 5
Sensitive Information in Complex Software
• Applications handle sensitive information– Credit card, personal ID, private keys, plaintext
information in general
• Large, buggy applications– 106 LOC in Firefox. 1.5 vulnerabilities per month. I.E.
averages 2 vulnerabilities per month [http://secunia.com]
• System services & kernel run at higher privilege levels– Vulnerabilities can be used to compromise
applications
Problem
04/18/23EuroSys2006Page 6
Reducing Complexity
• Build small, simple applications for handling sensitive data– [Saltzer74] advocated Economy of Mechanism, Least
Privilege and Separation of Privileges as important design principles
• Run these applications on a small Trusted Computing Base– A VMM based TCB is better as it is smaller and
simpler and exposes a narrow interface [Chen01].
• Rest of original application need not be trusted
AppCore
04/18/23EuroSys2006Page 7
Protecting Sensitive Information with AppCores
• Identify security-sensitive components of an application: Trusted Components– Currently, manual effort based on domain knowledge
• Extract components into an AppCore– Simplify components by limiting functionality
(Economy of Mechanism)– Modify original application to use AppCore
• Execute AppCore in trusted mode and the rest of application in untrusted mode (Separation of Privilege)
AppCore
04/18/23EuroSys2006Page 8
Reducing TCB Complexity: Nizza Architecture
1. Build TCB using small isolated componentsL4 microkernel + system services running as trusted processes
2. Use trusted wrappers to reuse untrusted components. e.g., TCP stack can be moved out of TCB by using SSL in TCB
3. Support legacy code L4Linux, a paravirtualized Linux kernel, that maintains ABI compatibility
AppCore
Shaded boxes = Trusted Components, clear boxes = Untrusted Components
04/18/23EuroSys2006Page 9
Case Study 1: E-commerce Transaction Client
• Internet browser is application of choice.– Average of 2 vulnerabilities per month over 3 years
for IE, 1.5 pm for Firefox [http://secunia.com]
• Sensitive Information: Customer’s payment information / profile information.
• Parser, UI modules, security library are security-sensitive components– Around 500 KLOC
• Refine these components based on functionality to reduce size.
Case Studies
04/18/23EuroSys2006Page 10
E-Commerce Transaction Client AppCore
Case Studies
04/18/23EuroSys2006Page 11
Case Study 2: VPN Gateway
• Many implementations based on Linux Kernel (> 150KLOC) and a security library– Implementations tightly coupled with kernel– TCP stack (> 40KLOC) also in TCB
• Sensitive information: Plaintext data & IPSec keys
• Data Protection & Policy Enforcement are security sensitive functions
• Other functions: network stack, routing, etc… in untrusted L4Linux partition.– Routing plain text data is handled by trusted ARP/IP
implementation
Case Studies
04/18/23EuroSys2006Page 12
VPN Gateway AppCore: Mikro-SINA
Case Studies
04/18/23EuroSys2006Page 13
Case Study 3: Signing Emails
• Signing module currently integrated in email clients
• Sensitive information: Private key of user • AppCore contains
– Display module that handles text– Cryptographic functionality (gpg library)
• Email client provides composer, implementation of SMTP, extensions, etc…
Case Studies
04/18/23EuroSys2006Page 14
Email Signer AppCore
Case Studies
04/18/23EuroSys2006Page 15
Evaluation
• Qualitative evaluation of Security
• Quantitative evaluation of Software Complexity
• Performance
Evaluation
04/18/23EuroSys2006Page 16
Qualitative Evaluation of Security
• Use of TCB allows us to have secure path between user and system– Secure output: Nizza controls a few pixels
on the top of the screen, identifying the trustworthiness of the in-focus application
– Secure input: trusted IO drivers– Makes spoofing more detectable.
• Economy of mechanism reduces attack profile of application.
Evaluation
04/18/23EuroSys2006Page 17
Software Complexity Metrics
• LOC as a baseline metric [Basili83]• McCabe’s complexity metric [McCabe76]
– A control flow complexity measure: Measures number of paths in a function.
– Disregards call nesting depth. We also measure call nesting depth separately.
• Complexity metrics are not perfect– Dependence on programming language/style– Pre-release vs. Post-release bugs
• But vulnerabilities are still found consistently in many applications.
Evaluation
04/18/23EuroSys2006Page 18
Software Complexity Reductions
Evaluation
Scenario
Original Application
AppCoreReduction FactorLOC
(x103)MCC (x103)
LOC (x103)
MCC (x103)
e-commerce(Browser)
978 151 10 1.5 100X
VPN Gateway (FreeS/WAN)
155 25 74 10 2.1X
Email signer (Thunderbird)
250 45 54 11 4.6X
TCB (Linux+Xserver)
1,485 238 100 14 14X
04/18/23EuroSys2006Page 19
Performance Impact
• Running on L4Linux reduces application performance by 5-10%.
• Data transfer rate between trusted and untrusted parts is around 800 Mbytes per second.
• E-Commerce transaction client AppCore has an overhead of 5 ms - 11%, but much smaller compared to human response time.
Evaluation
04/18/23EuroSys2006Page 20
Lessons Learned
• Security-Performance Tradeoffs– Performance impact of splitting applications– Point of separation: Moving the boundary of
separation in Mikro-SINA
• Reuse existing interfaces while splitting applications– Packet level IP interface in Mikro-SINA and
plugins for browser and email client
Lessons
04/18/23EuroSys2006Page 21
… Lessons Learned
• Refining AppCores is expensive but is worth the effort– Refining browser parser and security library provides
order of magnitude savings.– Replacing ~150KLOC L4Linux with 10 KLOC ARP/IP
software in Mikro-SINA
• Availability vs. Confidentiality & Integrity– Reusing Untrusted components leaves us vulnerable
to DOS attacks. e.g., TCP stack– Moving untrusted components out of TCB reduces
code that has access to plaintext/unsigned data.
Lessons
04/18/23EuroSys2006Page 22
Summary of Related Work
04/18/23EuroSys2006Page 23
Future Directions
• Facilitate the process of refactoring applications– [Brumley04] points to steps in that direction,
but inadequate for our case studies• Evaluate AppCores with other metrics,
e.g., attack surface area [Howard03]– Use this information to improve refactoring
techniques• Explore use of Defensive programming to
improve resistance to DOS attacks [Qie02]
04/18/23EuroSys2006Page 24
Questions