Using ProgrammerWritten Compiler Extensions to Catch Security Holes

1
Using Programmer-Written Compiler Extensions to
Catch Security Holes

• Authors Ken Ashcraft and Dawson Engler
• Presented by Hong Chen
• CS590F
• 2/7/2007

2
Outline

• Motivation
• Example Range Checker
• Solution Details
• Belief Inference
• Analysis Issues
• Enforcing Obscure Rules
• Evaluation
• Discussion

3
Motivation (1)

• Problem
• Find security holes (security rules violation) in
  source code of system software
• Security rules
• Sanitize untrusted input before using it
• Do not release sensitive data to unauthorized
  users
• Observation
• Many rules are poorly understood and erratically
  obeyed
• Approach
• Use static analysis to check if security rules
  are obeyed

4
Motivation (2)

• Program analysis Intuition ? Tool
• Security rules
• Domain specific
• System specific
• High-level
• Metacompilation
• Make it easy for programmer to add rules

5
Example Range Checker (1)

• Security rule
• Integers supplied by untrustworthy sources should
  be range-checked before used for dangerous
  operations

6
Range Check (2)

• Checker needs to identify
• Untrustworthy sources that generate data
• Checks must be done to sanitize the data
• Trusting sinks that must be protected
• Untrustworthy sources
• System calls (sys_)
• Routines copy data from user space
  (copy_from_user, copyin)
• Data from network

7
Range Check (3)

• Sanitizing data
• Signed integers lower and upper bound
• Unsigned integers upper bound check
• Tricky integer overflow

8
Range Check (4)

• Trusting sinks
• Array index
• Loop bound
• Copying/allocation
• routines

Potentially 3 x 3 x 3 27 types of security
holes!
9
Implementation (1)
10
Implementation (2)

• State machine representation
• Metal high-level, state-machine language
• Compilation extension linked to xgcc
• States can be global or bound to expressions
• How it works?
• After xgcc translates each input function into
  its internal representation, the checker is
  applied down every possible execution path in
  that function

11
Implementation (3)
12
Advantages

• Propagate the knowledge of one programmer to many
• Security rules are subtle
• Find difficult-to-observe errors
• Catch error without running code
• Many errors are found in the drivers
• Lightweight

13
About the checker

• Ad hoc knowledge (security rules)
• Effective (range checker finds 100 errors in
  Linux)
• False negative
• False positive

14
Belief Inference

• Traditional checkers
• Hardwired knowledge
• MC
• Use code behavior to infer checking properties
• Inference
• Untrustworthy sources
• Trusting sinks
• Network Data

15
Driving Untrustworthy Sources

• Challenges
• There are many untrustworthy sources
• Difficult to analyze
• Use inference
• Untrustworthy input is often used in stylized ways

16
Deriving Trusting Sinks

• Normal checking sequence
• (1) OS reads data from unsafe source
• (2) Check the data
• (3) Pass it to a trusting sink
• What if (3) is missing?
• Something may be wrong

17
Network Data

• Challenge
• Network data is not trustworthy
• sk_buff holds network data
• Incoming or outgoing?
• Candidates
• If the fields were read more often than written,
  the structure is incoming
• If the checker sees the allocation of the
  structure, its outgoing

18
Analysis Transitive Tainting

• Allow tainted variables to transitively taint
  other variables

19
Analysis Inter-procedural Analysis (1)

• The user only provides the base unsafe sources
  and trusting sinks
• Automatically compute all procedures that
  transitively produces or consumes data
• Two-pass process
• First pass Emit a call graph, compute the
  transitive set of functions, store calculated
  sources and sinks in text files
• Second pass at call sites, taint variable /
  report errors
• Special case function pointers

20
Analysis Inter-procedural Analysis (2)
21
Analysis False Positives

• Checker design
• First write simple checkers
• Eliminating false positives
• Common false positives
• Fancy bound checks
• Taint granularity
• Subroutine checks bounds

22
Analysis False Negatives

• First of all, false negatives are expected
• Potential improvements
• Comparison with correct value
• Other information flow channel (tainted value
  stored in data structure)
• Info lost during inter-procedure analysis
• Only local inference

23
Enforcing Obscure Rules (1)

• The length-field copy attack
• Signed integer must be lower and upper bound
  checked

24
Enforcing Obscure Rules (2)

• Integer overflow
• Fixed size arithmetic

25
Evaluation (1) Errors Overview

• Severe erros as common as minor ones

26
Evaluation (2) Errors Overview

• Most bugs are local
• Low false positive rate

27
Evaluation (3) Results Validation

• Linux (2.4.5 2.4.12)
• Post errors to Linux Kernel
• Count unique errors
• Many resulted in kernel patch
• False result kernel developers will explain why
• Minor bugs may introduce possibility of new
  bugs
• OpenBSD (2.9)
• Submitted to a local BSD hacker
• All errors resulted in kernel patches
• Total kernel patches 50

28
Discussion (1)

• Core techniques
• Static analysis State Machine model, although
  implementation details are not given (see
  details)
• Make ad hoc knowledge powerful
• Belief inference (save effort to specify
  everything)
• Extract information from source code presentation

29
Discussion (2)

• How to do better?
• Static analysis (other models/tools?)
• Finding errors (combine with dynamic analysis?)
• Other applications
• Finding bugs (past work)

30

• Thank you ?

31
Reference

• Using Programmer-Written Compiler Extensions to
  Catch Security Holes
• Ken Ashcraft and Dawson Engler
• In Proceeding of IEEE Security and Privacy
  2002.