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@auburn.edu

2. Introduction • Another software virus, another attack…is 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 software…possibly 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 indexing…out of bounds access and assignment • Format string manipulation • System software…root privileges, system() call • Changes to system environment variables • Host name attacks…spoofing a DNS response • Signals…interrupting software in a privileged state • Core dumps…values 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

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 findings…manual analysis still catches overlooked problems • Application library code is not automatically scanned • Analysis is time consuming…checker only cuts ¼ to 1/3 of that effort • Nevertheless…every 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 paradigm…a functional paradigm • May hold the key to building software that is provably secure

15. Questions? tevisjj@auburn.edu