testing

on testing

• challenges with testing for security:

  ---

• security bugs errors may not trigger error/crash
  • tools tool help with this for some types of bugs: AddressSanitizer, -fsanitize=undefined, taint tracking, …
  • can enable expensive checks when testing that we would not do otherwise
• security bugs use ‘‘unrealistic’’ inputs — e.g. \(>8000\) character name

automatic testing tools

• basic idea: generate lots of random inputs — ‘‘fuzzing’’

  • easy to generate weird inputs

• look for memory errors

  • segfaults, or
  • use memory error detector, or
  • add (slow) ‘assertions’ or other checks to code

• one of the most common ways to find security bugs

‘blackbox’ fuzzing

fn fuzz_test_image_parser(original_image: Vec<u8>) {
    let rng = rand::rng();
    for _ in 0..NUM_TRIES {
        let mut test_image = original_image.clone();
        let number_of_changes = rng.random_range(0..MAX_CHANGES);
        for _ in 0..number_of_changes {
            test_image[rng.random_range(0..test_image.len())] ^= rng.random::<u8>();
        }
        let result = try_to_parse_image(&test_image);
        if result == CRASH {
            // report that test_image triggers a bug
        }
    }
}

blackbox fuzzing pros

• works with unmodified software

  • even with embedded assembly, etc.

• works with many kinds of input

  • don’t need to understand input format

• easy to parallelize

  ---

• has actually found lots of bugs

what can fuzzing find

• easiest to find crashes

  • intuition: segfault could be security problem

• otherwise: how do we know if test cases are useful?

  ---

• need some way to know if test result is correct

• example: fuzz-testing of C compilers versus other C compilers

  • Yang et al, ‘‘Finding and Understanding Bugs in C compilers’’, 2011
  • 79 GCC, 209 Clang bugs
  • about one third ‘‘wrong generated code’’
  • but using smarter fuzzing strategy (we’ll talk about it later)

testing for non-memory flaws?

• fuzzing for cross-site scripting bugs?

  • run on web application
  • assert that HTML is well-formed?

• fuzzing for SQL injection?

  • assert that no malformed SQL gets executed?

• operating system?

  • input = requests (system calls) to make to the OS

• (less likely) fuzzing for permissions issues?

  • assert that admin. data doesn’t change?

weird things the tested program does

• need to detect crashes, ideally automatically
  • likely to find multiple crashes
• need to detect hangs
  • usually: set threshold amount of time, but…
  • … only useful if program consistent/fast enough
  • won’t find many bugs if we spend our time running hanging test cases
• need to handle resource exhaustion
  • stop tested program before it uses all the system’s memory/etc.

how many tests do we want?

• let’s say we’re making random changes to 512 byte image to find bugs
  • or even systematic changes (like trying every bit/byte/etc.)

    ---

• if our bug involves changing a particular byte
  • need 100s of tests to find that
• if it also needs changing to a particular value
  • need 100s of tests with the right byte to find that
  • or 10000s of tests
• if it needs changing another byte too
  • need 10000000s of tests?

some speeding up fuzzing ideas

• prefer shorter/lower-resource test cases
• test components separately more
  • custom “harness” that just runs one part of program at a time
• avoid restarting program for each test (needs way to reset state)
  • make version of program that reads many test cases per run
  • (forward reference: AFL++’s “persistent” mode)
• run test in way that avoids I/O
  • produce output, but don’t write it anywhere
  • preload/hardcode any configuration files
• do lots of tests in parallel

completeness problem

• let’s say we’re testing an HTML parser
• what code is usually going to run when we flip random bits?
  • (or remove/add random bytes)

    ---

• how often are we going to generate tags not in starting document?
• how often are we going to generate new almost-valid documents?

CSmith

• Yang et al wrote a random C program generator
  • “Finding and Understanding Bugs in C compilers” (PLDI 2011)

• carefully avoided code with unspecified effects
  • most of the work was about doing this
• don’t need to know what program does: comparing two compilers
  • or one compiler with different settings

    ---

• random selection of types, operators, etc.
• … instead of just random bytes

coverage

• ‘‘coverage’’: metric for how good tests are

  ---

• % of code reached

• easy to measure

• correlates with bugs found

  • but not the same thing as finding all bugs

coverage-guided example (1a)

void foo(int a, int b) {
    if (a != 0) {
        // W
        b -= 2;
        a += b;
    } else {
        // X
    }
    if (b < 5) {
        // Y
        b += 4;
        if (a + b > 50) {
            // Q
            ...
        }
    } else {
        // Z
    }
}

coverage-guided example (1b)

void foo(int a, int b) {
    if (a != 0) {
        // W
        b -= 2;
        a += b;
    } else {
        // X
    }
    if (b < 5) {
        // Y
        b += 4;
        if (a + b > 50) {
            // Q
            ...
        }
    } else {
        // Z
    }
}

coverage-guided example (1c)

void foo(int a, int b) {
    if (a != 0) {
        // W
        b -= 2;
        a += b;
    } else {
        // X
    }
    if (b < 5) {
        // Y
        b += 4;
        if (a + b > 50) {
            // Q
            ...
        }
    } else {
        // Z
    }
}

coverage-guided example (2a)

void foo(unsigned a,
         unsigned b,
         unsigned c) {
    if (a != 0) {
        b -= c; // W
    }
    if (b < 5) {
        if (a > c) {
            a += b; // X
        }
        b += 4; // Y
    } else {
        a += 1; // Z
    }
    assert(a + b != 7); 
}

coverage-guided example (2a)

void foo(unsigned a,
         unsigned b,
         unsigned c) {
    if (a != 0) {
        b -= c; // W
    }
    if (b < 5) {
        if (a > c) {
            a += b; // X
        }
        b += 4; // Y
    } else {
        a += 1; // Z
    }
    assert(a + b != 7); 
}

exercise: coverage guidance good for?

void example1(int a, int b) {
    if (a < 4 && b < 4 && a == b) {
        assert(a + b != 6);
    }
}
void example2(int a, int b) {
    assert(a != 10325);
}
void example3(int a, int b) {
    assert(a != 10325 && b != 10543);
}

• exercise: for which of these functions would coverage guided fuzzing be most/least better than random testing for making the assertion fail?

american fuzzy lop / AFL++

• most well-known fuzzer using this strategy
  • american fuzzy lop (2013-2016; Michal “lcamtuf” Zalewski)
  • AFL++ (later; community-maintained updated version)

    ---

• compiler “plugins” to record computed/conditional jumps:
• CoverageMap[EdgeID]++;
  • EdgeID = Hash(Source, Dest) or (more recently) unique conditional jump ID
  • “coverage map” = big array of bytes
  • counter so we can handle loops that run different amounts
  • usually saturating add (so once it gets to 256, it stays there)
• use values from coverage map to distinguish cases
• outputs only unique (coverage map) test cases

american fuzzy lop / AFL++ heuristics

• deterministic tests based on base inputs
  • try flipping every bit, every 2 bits, etc. of base input
  • overwrite bytes with 0xFF, 0x00, etc.
  • removing each byte/blocks of bytes of input
  • etc.
• multiple strategies for producing new inputs
  • bit-flipping
  • duplicating important-looking keywords
  • combining existing inputs
• base case selection
  • prefer cases that run faster/are shorter
  • see if removing/zeroing bytes/etc. can simplify an input without changing coverage
  • select set of “favored” cases covering each edge (source+dest of branch)

simplifying testing cases

int array[10];
void vulnerable(char *input) {
    char *p;
    int count = 0;
    p = input;
    if (*p == 'A') { 
        p += 1;
        while (*p == '0') {p += 1; count -= 1;}
        while (*p >= 'A' && *p < 'E') p += 1;
        while (*p == '0') {p += 1; count += 1;}
    }
    if (*p == 'B')
        array[count] += 1;
}

• example crash: A00ABDBBBDEEDDDCCCBBBDDDAAAA00000000000000000000000B

  • might be what coverage-guided fuzzing finds

• would really prefer minimal example: AA00000000000B

automatically simplifying test cases

• but look for same result and/or coverage

• systematic simplifications:

  • try removing every character (one-by-one)
  • try decrementing every byte
  • …

• keep simplifications that don’t change result

• AFL uses some of this strategy to help get better ‘base’ tests

  • also has tool to do this on a found test
  • prefers simpler ‘base’ tests

CReduce

• Regher et al, “Test-Case Reduction for C Compiler Bugs” (PLDI 2012)

• take a C program that triggers bug…

• try removing things to make it smaller

• needed: automated way of checking “is bug still there”

  • compilers: took advantage of multiple implementations

    ---

• same idea applies to security bugs

  • remove as much as possible and get it to still segfault, etc.

AFL: manual keywords

• AFL supports a dictionary
  • list of things to add to create test cases
  • example: all possible HTML tags
• compiler plugin to generate automatic dictionary
  • outputs constants/strings compared with
• AFL’s random mutations try inserting values from dictionary

• other strategy: test-case template
• other strategy: test postprocessing (fix checksums, etc.)

efficiency of finding new coverage

• PNG files have chunks with 4-byte type labels
• parser code something like:

uint32_t image_chunk_type;
fread(&image_chunk_type, 4, 1, image_file);
...
if (image_chunk_type == CHUNK_TYPE_PALETTE) {
    ...
}

• if we make random changes to 512-byte PNG image, how long till we enter that if statement?
  • need to randomly chnage 4 bytes containing “chunk type”
  • need to randomly choose CHUNK_TYPE_PALETTE
  • (or have CHUNK_TYPE_PALETTE in “dictionary”)

comparison log example

void foo(unsigned a, unsigned b, unsigned c) {
    if (a != 0) { // (1)
        b -= c; // W
    }
    if (b < 5) { // (2)
        if (a > c) { // (3)
            a += b; // X
        }
        b += 4; // Y
    } else {
        a += 1; // Z
    }
    assert(a + b != 7);  // (4)
}

using comparison logging: exercise (1)

• exercise 1: If I want to make the first comparison true, what should I change from a=0,b=0,c=0?
• exercise 2: If I want to make the second comparison true, what should I change from a=0,b=0,c=0?

using comparison logging: exercise (2)

• exercise: good new test cases?