Methods For The Prevention, Detection And Removal Of Software

Security Vulnerabilities

Jay-Evan J. TevisDepartment of Computer Science and Software Engineering

Auburn University, Alabamatevisjj@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