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