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