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?
- Slides: 10