Methods For The Prevention, Detection And Removal Of Software

Security Vulnerabilities

Jay-Evan J. TevisDepartment 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

9

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