Lecture Notes on Risk Analysis for Software | CS 475, Study Guides, Projects, Research of Cryptography and System Security

Download Lecture Notes on Risk Analysis for Software | CS 475 and more Study Guides, Projects, Research Cryptography and System Security in PDF only on Docsity!

Cs 475: Lecture 4

Software Security Defenses

Rachel Greenstadt

January 15, 2009

Reminders

Blog posts (or comments) due today

Security reviews also due today (11:59 pm)

gdb example up on website (start project!)

Common Defense

Methods

Security by Correctness (no more bugs)

“Safe” programming languages

Code verification

Fuzz testing

Security by Architecture (hard to exploit bugs)

Stack protection mechanisms

Obfuscation

Security by Isolation (Sandboxing - Tuesday)

Security by Response (Patching)

“Safe” Programming

Languages

Just write it in (Java, C#, ML, Haskell, etc)?

Memory safety - Can’t arbitrarily copy bits from one location to another

Type Safety “A language is type-safe if the only operations that can be

performed on data in the language are those sanctioned by the type of

the data."

Bugs still exist

Still a good idea (like birth control that way)

Not all code can be written (or rewritten) in these languages practically

Efficiency, low-level access needed, legacy code

Manual Code

Verification

A lot of evidence that peer reviews help find bugs,

improve software quality

People write better code if their colleagues are

going to look at it

Teaches people about secure software

Good code review catches ~50% of bugs

[McGraw]

Michael Howard’s 19 Deadly Sins of Software

• Buffer Overflows
• Format String problems
• SQL injection
• Command injection
• Failure to handle errors
• Cross-site scripting
• Failing to protect network traffic
• Use of "magic" URLs and hidden forms
• Improper use of SSL
• Use of weak password-based systems
• Failing to store and protect data
  • Information leakage
  • Improper file access
  • Integer range errors
  • Trusting network address information
  • Signal race conditions
  • Unauthenticated key exchange
  • Failing to use cryptographically strong random numbers
  • Poor usability

Two Types of Static Analysis

• The type you write in 100 lines of python.
  • (^) Look for known unsafe string functions strncpy(), sprintf(), gets()
  • Look for unsafe functions in your source base
  • Look for recurring problem code (problematic interfaces, copy/ paste of bad code, etc.)
• The type you get a PhD for
  • Buy this from coverity, fortify, etc.
  • Built into visual studio
  • Roll your own on top of LLVM or Phoenix if hardcore

Static Analysis Basics

• Model program properties abstractly, look for problems
• Tools come from program analysis
  • Type inference, data flow analysis, theorem proving
• Usually on source code, can be on byte code or disassembly
• Strengths
  • Complete code coverage (in theory)
  • Potentially verify absence/report all instances of whole class of bugs
  • Catches different bugs than dynamic analysis
• Weaknesses
  • High false positive rates
  • Many properties cannot be easily modeled
  • Difficult to build
  • Almost never have all source code in real systems (operating system,

shared libraries, dynamic loading, etc.)

Example: Where is the bug? int read_packet(int fd) { char header[50]; //model (header, 50) char body[100]; //model (body, 100) size_t bound_a = 50; size_t bound_b = 100; read(fd, header, 100); read(fd, body, 100); return 0; }

Example: Where is the bug? int read_packet(int fd) { char header[50]; //model (header, 50) char body[100]; //model (body, 100) size_t bound_a = 50; size_t bound_b = 100; read(fd, header, 100); //constant propagation read(fd, body, 100); //constant propagation return 0; }

Example: Where is the bug? int read_packet(int fd) { char header[50]; //model (header, 50) char body[100]; //model (body, 100) size_t bound_a = 50; size_t bound_b = 100; //check read(fd, 50 >= 100) => SIZE MISMATCH!! read(fd, header, 100); //constant propagation read(fd, body, 100); //constant propagation return 0; }

Rarely are Things This Clean

• Need information across functions
• Ambiguity due to pointers
• Lack of association between size and data type…
• Lack of information about program inputs/ runtime state…

Care and Feeding of Static Analysis Tools

• Run and Fix Errors Early and Often
  • otherwise false positives can be overwhelming.
• Use Annotations
  • Will catch more bugs with few false positives
• Write custom rules!
  • Static analysis tools provide institutional memory
• Take advantage of what your compiler provides
  • gcc -Wall, /analyze in visual studio
• Bake it into your build or source control

Normal Dynamic Analysis

• Run program in instrumented execution environment - Binary translator, Static instrumentation, emulator
• Look for bad stuff
  • Use of invalid memory, race conditions, null pointer deref, etc.
• Examples: Purify, Valgrind, Normal OS exception handlers (crashes)