Fuzz Testing by Biased Thread Scheduling WorkinProgress Update

Fuzz Testing by Biased Thread Scheduling Work-in-Progress Update Derek Hower Andrew Phelps March 30, 2007

What We’re Doing l Parallel software: l l 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: l l Lightweight threads (shared data) Specifically, pthreads NPTL on Linux Using our desktop machines (so far)

Perturb How? l l Modify the scheduling of threads Software can unconsciously rely on a particular thread running at a particular time l l 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? l l l Where does one find apps that use pthreads? Actually, lots of places… We have chosen an initial set of applications to test: l l Open. Office ffmpeg video encoding library My. SQL database Apache web server

Choice of Three Approaches l We identified a main approach and two backups: l l l 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 l l l Peach, the multithreaded fuzz tester Basically a specialized debugger Mixed success l l Poorly documented libraries = major headache! We are currently able to attach, monitor some events

Peach Basics l l 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 l l l 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?