1 / 10

Fuzz Testing by Biased Thread Scheduling

Fuzz Testing by Biased Thread Scheduling. Work-in-Progress Update Derek Hower Andrew Phelps March 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

nash
Download Presentation

Fuzz Testing by Biased Thread Scheduling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. Focus On: • Lightweight threads (shared data) • Specifically, pthreads • NPTL on Linux • Using our desktop machines (so far)

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. Questions?

More Related