Fuzz Testing by Biased Thread Scheduling

Work-in-Progress Update

Derek HowerAndrew PhelpsMarch 30, 2007

What We’re Doing

Parallel software: is notoriously hard to get right often works “by chance” but harbors latent bugs

Better testing is needed for better software …So we will randomly perturb programs to

scare up the crashes

Focus On:

Lightweight threads (shared data) Specifically, pthreads NPTL on Linux Using our desktop machines (so far)

Perturb How?

Modify the scheduling of threads Software can unconsciously rely on a particular

thread running at a particular time For awhile after returning from a call Through an area that should have been protected with a

lock

We will be unfair to the threads, and arbitrarily stop some and prefer others

We will increase the number of times that threads are switched at arbitrary points

What Software to Break?

Where does one find apps that use pthreads? Actually, lots of places… We have chosen an initial set of applications

to test: OpenOffice ffmpeg video encoding library MySQL database Apache web server

Choice of Three Approaches

We identified a main approach and two backups: We want to use ptrace, libthread_db to control the

target app If that runs into difficulty, we could simply hack

pthreads Or, worst case, hack the kernel scheduler

Current Progress

Peach, the multithreaded fuzz tester

Basically a specialized debugger

Mixed success Poorly documented

libraries = major headache!

We are currently able to attach, monitor some events

Peach Basics

1 shadow Peach thread per target thread Scheduling decisions made in shadow when

the target cedes control

Main Peach Controller

Shadows Target Threads

Moving Forward

Still developing foundation With any luck, actual fuzz testing will begin

shortly Finding source of any bugs we do find looks

doubtful given the current timeframe

Questions?