View
213
Download
0
Tags:
Embed Size (px)
Citation preview
Methods For The Prevention, Detection And Removal Of Software
Security Vulnerabilities
Jay-Evan J. TevisDepartment of Computer Science and Software Engineering
Auburn University, Alabama
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