Methods For The Prevention, Detection And Removal Of Software Security Vulnerabilities

1
Methods For The Prevention, Detection And Removal
Of Software Security Vulnerabilities

• Jay-Evan J. Tevis
• Department of Computer Science and Software
  Engineering
• Auburn University, Alabama
• tevisjj_at_auburn.edu

2
Introduction

• Another software virus, another attackis another
  security patch the best answer?
• How did the security vulnerability get there in
  the first place?
• Flaw in a requirement? Part of the design?
• Already existed in source code or object code?

3
Introduction

• Recommended security defense techniques
• Filter all data followed by an accept or reject
  decision
• Assume all input is bad until proven otherwise
• Perform data validation both at input points and
  at the component level
• Accept command input from a user only after
  parsing it
• Make policy decisions based on a "default deny"
  rule

4
Introduction

• Strategies to decrease security vulnerabilities
• Audit all source code (via static code analysis)
• Perform formal software verification
• Authenticate all software
• Give security concerns a higher priority
• Apply experience-based validation to test against
  known attacks
• Use tiger teams to maliciously exploit the
  software

5
Introduction

• This paper's focus static analysis of source
  code
• Strong point of analysis? concentrates on
  functions and data constructs that pose a
  security risk
• Weak point of analysis? uses a reactive approach
  to problem detection
• Need a better answer to ensuring secure
  softwarepossibly a paradigm shift away from
  imperative programming and towards purely
  functional approaches

6
Overview

• Specific security vulnerabilities to avoid in
  source code
• Inventory of static code security checkers
• Critique of static code security checkers
• Software security assurance from a functional
  programming perspective
• Related areas
• Future work

7
Specific Security Vulnerabilities To Avoid In
Source Code

• Public enemy 1 ? Buffer overflow
• Distance cousin ? Heap overflow
• Array indexingout of bounds access and
  assignment
• Format string manipulation
• System softwareroot privileges, system() call
• Changes to system environment variables
• Host name attacksspoofing a DNS response
• Signalsinterrupting software in a privileged
  state
• Core dumpsvalues of constants, variables, and
  registers

8
Inventory of Static Code Security Checkers

• Static code security checkers
• Identify potential security problems
• Find known or previously identified conditions
• Goal focus the security analysis of the code
• Subgoals suggest remedies and provide assessment
• List of static code security checkers

9
(No Transcript)
10
Critique Of Static Code Security Checkers

• Focus mainly on Unix applications or standard C
  library function calls
• Require a high level of expert knowledge to
  evaluate the findingsmanual analysis still
  catches overlooked problems
• Application library code is not automatically
  scanned
• Analysis is time consumingchecker only cuts ¼ to
  1/3 of that effort
• Neverthelessevery little bit helps, focuses
  attention, finds real bugs

11
Software Security Assurance From a Functional
Programming Perspective

• Imperative programming ? assignment, control
  loops, environment state, array indexing, memory
  addresses
• Functional programming ? referential
  transparency, recursion, pattern matching,
  mathematical foundation, formal specification,
  proof of correctness

12
Related Areas

• Runtime checkers
• Located between application and operating system
• Intercept and screen system calls
• Examples Libsafe, PurifyPlus, Immunix
• Use profiling of software
• Observation period to identify normal behavior
  followed by monitoring to watch for abnormal
  actions
• Testing for buffer overflow vulnerability
• Examples NTOMax, SendIP

13
Future Work

• Consolidate and correlate measures used by static
  code checkers written in imperative languages
• Build prototype static code checkers in both
  logical and functional languages (i.e., Prolog
  and Haskell)
• Identify imperative-to-functional conversions of
  most common security-vulnerable imperative code
• Incorporate conversion recommendations into
  static code checkers

14
Conclusion

• Threat from malicious users is real and the
  target is soft
• Methods exist to reduce security vulnerabilities
• Imperative approach may be the root cause to
  vulnerabilities
• Time for functional programming to prove its
  worth
• Move from the von Neumann paradigm into a
  mathematically sound paradigma functional
  paradigm
• May hold the key to building software that is
  provably secure

15
Questions?
tevisjj_at_auburn.edu