CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz

Application-level security

 I.e., programming-language security  Previous focus was on protocols and algorithms to prevent attacks –Are they implemented correctly?  Here, focus is on programming errors and how to deal with them –Reducing/eliminating/finding errors –Containing damage resulting from errors

Classifying flaws  Intentional flaws –E.g., “backdoors”  Unintentional flaws –E.g., programmer errors

Buffer overflows  50% of reported vulnerabilities  Overflowing a buffer results in data written elsewhere: –User’s data space/program area –System data/program code Including the stack, or memory heap  Can also occur in other contexts –E.g., parameters passed via URL

Example  Suppose a web server contains a function: void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); }  When the function is invoked the stack looks like:  What if *str is 136 bytes long? strret-addrsfpbuf top of stack str top of stack *str ret

Basic exploit  Suppose stack looks like:  When func() exits, user will be given a shell !!  Note: attack code runs in stack top of stack *str ret Code for P Program P: exec( “/bin/sh” ) (exact shell code by Aleph One)

Finding buffer overflows  Hackers find buffer overflows as follows: –Run web server on local machine –Issue requests with long tags. All long tags end with “$$$$$” –If web server crashes: search core dump for “$$$$$” to find overflow location.

Incomplete mediation  E.g., changing symbolic link between checking and use  E.g., parameters passed via URL –Parameters may be checked at client-side… –…but checking still necessary server-side  E.g., changing prices in URL…

Cross-site scripting  Violation of privacy…  General rule: always check inputs from untrusted source!

Time-to-check vs. time-of-use  “Serialization/synchronization” flaw  E.g., presenting command; then changing command while it is being verified

Covert channels  Intentionally inserted by programmers into software, to later leak information…  Examples in book…e.g., spacing information in printed page, formats, etc.  Other examples: “file lock” channel, existence/non-existence of file, etc.

Analysis of covert channels  “Shared resource matrix” –Tabulates subjects and the resources thave have access to  Information flow analysis (in source code) –E.g., “B = A” supports info. flow from A to B –“If (D == 1) then B = A” supports info. flow from D to B also! –Trace information flow throughout program…

Timing attacks  Password checking routines…  Web caching

Finding/preventing flaws

Penetration testing?  Limited to finding/patching existing flaws –Cannot be used to guarantee that software is free of all flaws  Patching flaws in this way has its own problems –Narrows focus to fixing a specific flaw, rather than addressing issues more broadly –May introduce new flaws

Automated testing  Successful to some extent  Hard to catch all flaws –Traditional program verification/testing focuses on what a program should do –Here, we are concerned with things a program should not do

Techniques for preventing flaws  Secure programming –Developmental controls –Better techniques –Secure programming languages –Static analysis  Secure compilation –Dynamic analysis –Software fault isolation

Techniques…  Inferring trust –Source authentication/code signing –Proof-carrying code  OS controls –Sandboxing –System-call interposition techniques –Secure boot of OS

Developmental controls…  Modularity –Improves ability to locate flaws –Easier to verify/fix code  Encapsulation/information hiding  Peer review/testing/analysis  Automated code testing

Secure programming techniques (Based on: “Programming Secure Applications for Unix-Like Systems,” David Wheeler)

Overview  Validate all input  Avoid buffer overflows  Program internals…  Careful calls to other resources  Send info back intelligently