Static Checking of C Programs for Vulnerabilities. Aaron Brown

Transcription

1 Static Checking of C Programs for Vulnerabilities Aaron Brown

2 Problems 300% increase in reported software vulnerabilities SetUID programs Run with full access to the system Required to gain access to certain functions C Programming Language No built-in memory safety Easy to accidently add vulnerabilities to code

3 Vulnerability Types Buffer Overflows Race Conditions TOCTOU vulnerabilities Improper System Interactions Not dropping privledge properly Insecure chroot jails File Descriptor attacks

4 Proposed Solution: Formal Proof Methods Attempt to prove the correctness of the code Requires specific knowledge of exactly what needs to be proved Downsides Can't easily apply to already written programs Expensive How do you verify the formal specification? Not in wide use

5 Proposed Solution: Fix C Fix C's Memory Management Issues Purify, Stackguard, Electric Fence, Valgrind Problems with these methods Specific to C Don't necessarily verify every execution path Don't necessarily fix the actual problem

6 Proposed Solution: Fix Standard Libraries Implement new system libraries to prevent issues Ensures future users do not fall into the same trap Example: mkstemp Problems May not work with prewritten software Change to new interface may be non-trivial

7 Proposed Solution: Change Languages Languages like Java, Perl, Python provide the memory safety that C lacks. Downsides Much infrastructure relies on C Loss of years of debugging Many projects may need the low level access C provides Other languages could still have security vulnerabilities.

8 Proposed Solution: Model Checking Benefits Explains why something is happening Can be applied to any language Can be run on pre-existing code bases Can check every execution path Generally Extensible Downsides Can not tell one that no bugs exist May generate false alarms

9 Model Checking Example: MOPS Limited model checker Doesn't check multithreaded programs Doesn't check for memory safety Can't understand inline assembler Doesn't understand variable aliasing

10 Model Checking Example: MOPS Still very useful Can detect many types of race conditions Can ensure that subtle security issues are handled properly

11 Model Checking Example: MOPS Overview Static analysis tool Pushdown model checking Simplified variable handling Simplified branch handling

12 Model Checking Example: MOPS Security Properties Checks temporal safety properties described by a Finite State Automata

13 Example of a Security FSA // The program has root privilege if ((passwd = getpwuid(getuid())!= NULL){ } fprintf(log, drop priv for %s, passwd- >pw_name); setuid(getuid()); execl( /bin/sh, /bin/sh, NULL); // risky syscall Untrusted Privledged Execution

14 Security FSA in MOPS Syntax setuid_exec.mfsa: setuid.fsa q priv f priv_exec setuid.fsa t priv priv_exec { function_call { identifier execv } { ellipses } } t priv nopriv {function_call{identifier seteuid}{function_call {identifier getuid}}} t priv_exec priv_exec { other } t nopriv priv {function_call{indentifier seteuid}{ lexical_cst 0 }}

15 Example of a Security FSA stat(logfile, &st); if (st.st_uid!= getuid()) return -1; open(logfile, O_RDWR); File Access Race Condition

16 Security FSA in MOPS Syntax file_race.mfsa access.fsa q none_passed f two_passwd access.fsa t none_passed one_passed {binary = {var x}{function_call{identifier{ open }}} t none_passed one_passed {binary = {var x}{function_call{identifier{ stat }}} t none_passed one_passed {binary = {var x}{function_call{identifier{ rename }}} t one_passed two_passed {function_call{identifier{ open }{var x}}} t one_passed two_passed {function_call{identifier{ stat }{var x}}} t one_passed two_passed {function_call{identifier{ rename }{var x}}} t one_passed one_passed {other} t two_passed two_passed {other}

17 Extending the Model Many attacks unrelated to unsafe system calls Cross Site Scripting SQL Injection

18 Example of a Security FSA Perl Code: // The server can write to the database $user_data = read_user_data(); if (user_data!= ) { $db->execute($user_data); } else { } print_error( Invalid Data ); SQL Injection

19 Viability of MOPS - Performance Performance depends on the complexity of the FSA and the amount of times the program calls the functions in the FSA Implementation in Java can run in a reasonable amount of time.

20 Viability of MOPS - Performance Performance of MOPS on the first DSA Apache 229k 0:45 BIND 279k 0:53 Samba 254k 1:53 Sendmail 222k 0:12 Performance of MOPS on the second DSA Apache 229k 0:43 BIND 279k 1:08 Samba 254k 13:14 Sendmail 222k 1:53

21 Viability of MOPS - Effectiveness Effectiveness Found 2 previously unknown issues in SSH Unsafe temp file handling Failure to drop priveledges properly Found many instances of standard file vulnerabilities At, Apache, OpenSSH, Samba and Vixie Cron

22 Other Checkers Stanford Checker Stanford Checker[DAWES] General Bug Checker Meta-Level Compilation Project from Stanford Modified GCC Doesn't use model checking

23 Other Checkers Stanford Checker Used against Linux and FreeBSD User pointers dereferenced An integer from userspace is used as an argument to a copy_*_user function or an array index Format string bugs

24 Other Checkers Static detection of buffer overflows David Larochelle and David Evans at UVA[DLDE] Extension of Split(LCLint) Uses annotations to tell the checker what the intent of the code is Produces a lot of spurious warnings until all the annotation has been done.

25 Questions?

26 References [DAWES] D. Engler, et al. Checking System Rules Using System-Specific, Programmer- Written Compiler Extensions OSDI. [DLDE] D. Larochelle and D. Evans. Statically Detecting Likely Buffer Overflow Vulnerabilities USENIX Security Symposium.