Code Review With a Tool

Software Security Building Security In

Ch.4: Code Review with a Tool

In this chapter… • Manual code review • Code review with a tool

About finding and fixing bugs

Manual code review • Steps – Make sure you know what you’re doing. – Prioritize. – Review the code. (Michael Howard, Microsoft – IEEE Security & Privacy jul/aug 2006 “A Process for Performing Security Code Reviews “)

• Danger: “get done, go home”

Code review: required knowledge • Common bugs • Language specific security issues – C/C++: memory management – buffer overflows – Java: concurrency issues – All: error management, metacharacters, injection

Code review: prioritize • • • • • • • • • •

Old code. Code that runs by default. Code that runs in elevated context. Anonymously accessible code. Code listening on a globally accessible network interface. Code written in C/C++/assembly language. Code with a history of vulnerabilities. Code that handles sensitive data. Complex code. Code that changes frequently.

Code review puzzle: spot the bug! void func(char *p, int i) { int j = 0; CFoo foo; int (*fp)(int) = &func; char b[128]; strcpy(b,p); }

Code review with a tool • Static analysis tools (source code analyzers) – Identify many common coding problems automatically – Examine the text of a program statically – without attempting to execute it

Dangers of source code analysis • False negatives

• False positives

Approaches to static analysis • Lexical analysis – No semantics

• Abstract Syntax Tree (AST) – Local analysis – one function at a time – Module-level analysis – takes into account relationships between functions in the same module – Global analysis – takes into account all relationships between functions

Java code sample public class Adder { int count; public void caller() { addCount(3, "Adding three"); } public int addCount(int x, String y) { count += x; return count; } }

AST example

Google Code Search

What to consider when selecting a tool • Ruleset quality – Size and coverage

• Analysis method – Pure lexical comparison is too simple – Should be based on compiler technology – …Model based…

Key characteristics of a good tool 1. 2. 3. 4.

Designed for security Support multiple tiers Be extensible Be useful for security analysts and developers alike 5. Support existing development processes 6. Make sense to multiple stakeholders

Characteristics of a tool to avoid 1. Too many false positives 2. Spotty integration with IDEs 3. Single-minded support for C