Making Open Source Software More Secure

1
Making Open Source Software More Secure

• Walter Chang
• Samuel Z. Guyer
• Teck Tok
• Calvin Lin
• The University of Texas
• February 2004

Ray Young Doc Shankar Linux Technology Center
2
Open Source Software

• Advantages
• Many eyes find bugs
• Many hands add features
• Contributors can add new features incrementally
• Disadvantages
• Many eyes find bugs
• Hackers can look for vulnerabilities
• Need tools to tame software development

3
State of the art related systems

• Type systems Wagner01, Foster02, Heine03
• MC Engler00
• SLAM Ball01
• ESP Das02
• CCured Necula02

4
State of the art issues

• Too expensive in human terms
• Requires manual analysis or modification of the
  source code
• Requires extensive annotation of source code
• Requires that humans reason about the results
• Analysis tradeoffs
• Precise analysis requires prohibitive amounts of
  time
• Imprecise analysis produces too many false
  positives

5
Pointer analysis is key

• Pointer analysis is important
• Most vulnerabilities in C programs are
  pointer/buffer related
• Many vulnerabilities span multiple functions in
  source code
• Pointer analysis is expensive
• High precision often leads to out of memory or
  non-termination
• Even a little increased precision can be expensive

6
Problems with pointer analysis

• Coarse-grained precision policies
• Uses the same precision everywhere all
  procedures context-sensitive, all memory
  locations flow sensitive, etc
• Extremely expensive in time and space
• Unnecessary precision Wasted work
• Not everything requires high precision

7
The problem with pointer analysis

• Real-life scenario
• Check for security vulnerabilities in BlackHole
  mail filter

Memory Model

• Manually inspect reported errors
• One thing in common a string processing routine
• Only this routine needs to be context sensitive
• Change this and all 85 false positives go away
• Can we automate this process?

8
Pointer analysis

• Pointer analysis not a stand-alone analysis
• Supports other client analyses
• Todays focus
• Client analysis analysis for detecting errors
• Pointer analysis algorithm choose precision

Memory Model
9
Our solution

• Problems
• Cost-benefit tradeoff severe for pointer
  analysis
• Precision choices are too coarse
• Choice is made a priori by the compiler writer
• Solution Mixed precision analysis
• Apply higher precision where its needed
• Use cheap analysis elsewhere
• Key Let the needs of client drive precision
• Customized precision policy created during
  analysis

10
Client-Driven Pointer Analysis

• Algorithm Guyer Lin 03
• Start with fast cheap analysis FI and CI
• Monitor how imprecision causes information loss
• Adapt Reanalyze with a customized precision
  policy

Memory Model
11
Algorithm components

• Monitor
• Runs alongside main analysis
• Records imprecision
• Adaptor
• Start at the locations of reported errors
• Trace back to the cause and diagnose

12
Programs

• 18 open source C programs
• Unmodified source all the issues of production
  code
• Many are system tools run in privileged mode
• Representative examples

13
Methodology

• 18 open source C programs
• 5 error checking problems
• Compare client-driven with fixed-precision
• Goals
• First, reduce number of errors reported
• Conservative analysis fewer is better
• Second, reduce analysis time

14
Results
Remote access vulnerability
10X
15
Why it works

• Notice
• Different clients have different precision
  requirements
• Amount of extra precision is small

16
Lessons

• Client-driven pointer analysis
• Precision should match the client and program
• Not all pointers are equal
• Need fine-grained precision policies
• Key knowing where to add more and what kind
• Blueprint for scalable analysis
• Use more expensive analysis on select parts of
  programs

17
Error Checking Open Source

• Handle large real-world programs
• Linux Kernel millions of lines of code
• Modular checking check kernel subsystems,
  drivers, components in isolation
• Server programs Apache, Samba, etc
• Check real-world problems
• Common Criteria certification Labeled Security,
  EALs
• CERT Advisories
• Provide useful results
• Improve error reporting and precision
• Give helpful diagnosis of error causes

18
Future Work

• Improve scalability
• Sendmail takes 2 hours to analyze in CI-FI mode
• Use even faster pointer analysis
  unification-based algorithm Steensgaard96
• Preliminary results Can analyze sendmail in 1
  minute
• Improve accuracy
• Add path-sensitivity
• Array accesses
• Array dependence testing
• Heap models
• Shape analysis

Path-sensitive. . .
CS-FS
CI-FS
CS-FI
CI-FI
Unification-Based
19
Future Work

• Linux Kernel
• Check device drivers
• Check subsystems
• Check system-wide interactions
• Linux System
• Check more security policies (eg, Labeled
  Security Protection Profile)
• Check application/system interactions

20
(No Transcript)