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. 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. 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. 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. 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. 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. 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. 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. 9

10. 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. 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. 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. 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. 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. 15 Questions? tevisjj@auburn.edu