CS463.11 Program Security

1
CS463.11Program Security

• UIUC CS463
• Computer Security

2
Software Security

• Software security perhaps most important topic in
  security
• Policies need mechanisms to enforce them
• Mechanisms (S/W) need to be implemented correctly
• Software currently the weakest link
• Prevalent problem
• A lot of current research

3
Best Practice

• Often, the best way to prevent flaws in programs
  is?
• Good programming!
• Unfortunately, this is hard to do.

4
Software security approaches

• Process
• Design, reviews, testing,
• Techniques
• Principles, idioms,
• Tools

5
Processes

• Good, well understood requirements
• Peer Reviewing, pairs programming, egoless
  programming
• Modularity

6
Testing

• Begins with the requirements
• Independent review
• Good testing is hard to do!
• Need to test for the uncommon case

7
Testing

• Testing the module
• Normal data tests
• Boundary data tests
• Exception tests
• Random data tests
• Testing composed modules
• Error handling tests
• Testing the program
• Has to be independent!

8
The use of tools

• Well designed tools can be an invaluable
  resource.
• Good programming is even harder to enforce then
  it is to do.
• Tools can make up for inevitable human error

9
Most common vulnerability

• Buffer overflows
• Memory safety
• Stack overflows
• Heap overflows
• Format string vulnerabilities
• 4 decades old and counting
• Many tools
• Slow progress being made

10
Lint

• Looks for common error patterns
• E.g. use of gets()
• Based on lexical analysis
• Later tools (Splint) more powerful
• Advantage fast, finds many errors
• Disadvantage finds human-visible errors

11
Fuzz

• Try to cause buffer overflows
• Give program large, random input
• See if it crashes
• Highly effective, finds many errors
• Can detect errors hard for people to see
• Operational approach to testing
• Only tests a fraction of the input space

12
Bug finding tools

• Bug finding tools improve code quality
• but always miss some bugs
• Software quality more a function of of bugs
  still remaining
• Remaining bugs are expensive to find
• But attackers have to find only one, so the odds
  are against us

13
Static Analysis

• Apply some analysis technique to source code
• Prove the absence of (certain) bugs
• Sounds great!
• Doesnt work

14
Halting Problem

• Two desirable properties for analysis
• Soundness - produces correct results
• Completeness - analyzes any program
• Soundness completeness undecidability
• if (undecidable_function())
• char x NULL
• x a

15
Static Analysis Guarantees

• Sound
• If the analysis verifies program as safe, then
  there are no bugs
• Not complete
• If the analysis cant verify program, there may
  be bugs
• (Often not sound)

16
False Positive Options

• Manual examination
• Make sure its a false positive
• Improve analysis
• E.g. add annotations
• Change program
• Make it more amenable to analysis

17
Static Analysis Process

• Success of static analysis has led to process
  changes
• Involve developers in analysis
• Error reporting needs to make sense
• Integrate analysis into development cycle
• Scalable, incremental analysis
• Require all code to be verified
• High completeness requirements

18
Static Analysis approaches

• Approaches
• Type-based analysis
• Model checking
• Meta-compilation
• Abstract interpretation

19
Dynamic Safety

• Detect memory safety violations at runtime
• Stop program on failure
• Fail-stop
• Impacts availability, but protects
  confidentiality integrity

20
Address Space Randomization

• Intuition similar to fuzz most memory errors
  cause the program to crash
• Exploits carefully craft memory errors to avoid
  crashes do evil
• Randomize memory layout to make such crafting
  difficult

21
Dynamic Checks

• Add checks at runtime
• Bounds checks
• Stack integrity checks
• Checks inserted by code rewriting
• At compilation time StackGuard, Purify
• In the binary libsafe
• Execution overhead
• Not 100 sound

22
Hybrid Approach

• Static analysis to prove most operations correct
• If static analysis cant prove it, insert a
  dynamic check
• Low overhead
• Sound complete!

23
CCured

• Use heavyweight static analysis on C code
• Prove memory safety properties of most code
• Insert dynamic checks
• Use annotations to improve performance
• Annotations direct analysis, but dont affect
  safety

24
Cyclone

• C-like language
• Porting effort relatively simple
• Simple static analysis rules
• Easy to understand for the programmer
• Code in restricted model proven safe
• Code in unrestricted model checked at runtime
• Costs of checks visible to the developer

25
Use other languages?

• Other languages ensure memory safety
• C
• Java
• Use automated memory management (garbage
  collection)
• Expensive
• Machines are bad at efficient memory management
  (though getting better)
• Humans are bad at correct memory management

26
Other vulnerabilities

• Whats the 2 software vulnerability?
• Using untrusted input in a sensitive context

27
Tainting analysis

• Use same approaches as information flow
• Type-based analysis (JIF, Cqual)
• Dynamic tainting (Perl)
• Before performing sensitive operations, check for
  tainted inputs

28
Tainting Analysis Problems

• Sensitive hard to define
• Depends on the application, user
• Untrusted input validated to be safe
• Successes mostly in contexts where both of these
  well-defined
• Format string vulnerabilities
• Kernel memory errors

29
Conclusion

• Software security an important problem
• Many tools to improve security
• Room for many more
• What will life be like after memory safety?
• Untrusted input
• Race conditions
• Interface mismatches