This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: is there a fuzzer for libc?


On Mon 02 Jun 2014 16:01:55 Rich Felker wrote:
> On Mon, Jun 02, 2014 at 11:17:29PM +0400, Konstantin Serebryany wrote:
> > Did anyone ever wrote a fuzzer for libc (generator of random inputs
> > for libc functions)?
> > We have an AddressSanitizer-instrumented build of glibc, it would be
> > interesting to give it some stress.
> 
> I actually saw a test report from some group that ran their fuzzer
> against glibc (I don't have the link right off) but most of the output
> was noise. Fuzzing C functions is difficult in principle because,
> unless the function takes no pointer arguments, the vast majority of
> possible inputs will invoke undefined behavior and there is
> fundamentally no way for the function to defend against this. So to do
> meaningful fuzzing, you need to exclude all such inputs (except
> possibly a set that ignorant programmers are likely to pass, and that
> you want to catch for hardening purposes) and generate calls that
> actually satisfy the interface contract of the function in nontrivial
> ways. For instance to fuzz printf- and scanf-family functions you need
> a valid format string and arguments of the right types, to fuzz glob
> you need an initially-valid glob structure, to fuzz wcsnrtombs you
> need appropriate buffers and correct length data for them, to fuzz
> getaddrinfo you need a valid hints structure, etc.

the trinity fuzzer used for the kernel does this to a degree.  it describes 
the types of input for each syscall before fuzzing the parts that make sense.  
like if the func needs a valid fd, it will set one up (and then do things like 
give it a socket or eventfd or fd to random device nodes).  or if it needs a 
specific structure and only some fields must be valid, it will do so, and then 
set up ranges for the other parts before randomizing.
http://codemonkey.org.uk/projects/trinity/
it's got a pretty good history of finding legit bugs, albeit it still gets to 
rely on the kernel to a degree for doing memory protection with bad user 
pointers.

not sure it'll be super applicable, but certainly worth taking a look.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]