|
Message-ID: <CAGQ9bdxQO-xCLBeL_J7R9ywqN_FMAyHaccQLyWNCNfoBDXfBcA@mail.gmail.com> Date: Fri, 20 Mar 2015 17:54:49 -0700 From: Konstantin Serebryany <konstantin.s.serebryany@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: buffer overflow in regcomp and a way to find more of those On Fri, Mar 20, 2015 at 5:46 PM, Rich Felker <dalias@...c.org> wrote: > On Sat, Mar 21, 2015 at 01:26:16AM +0100, Szabolcs Nagy wrote: >> * Konstantin Serebryany <konstantin.s.serebryany@...il.com> [2015-03-20 17:06:18 -0700]: >> > On Fri, Mar 20, 2015 at 4:52 PM, Szabolcs Nagy <nsz@...t70.net> wrote: >> > > * Konstantin Serebryany <konstantin.s.serebryany@...il.com> [2015-03-20 13:17:47 -0700]: >> > >> Following the discussion at the glibc mailing list >> > >> (https://sourceware.org/ml/libc-alpha/2015-03/msg00662.html) >> > >> I've tried to fuzz musl regcomp and the first bug popped up quickly. >> > >> Please let me know if you would be interested in adding the fuzzer >> > >> (http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Fuzzer/README.txt?view=markup) >> > >> to the musl testing process. >> > >> >> > > >> > > (now with correct To: header) >> > > >> > > >> > > (1) the clean approach would be to have a way to build an >> > > instrumented libc and a separate set of test cases for >> > > various libc apis that the fuzzer could use. >> > >> > Correct. Building libc.a is simple: >> > CC="clang -fsanitize=address -fsanitize-coverage=3 " ./configure && make -j >> > But then I don't know how to properly link libc.a to a test case. >> > How do you usually link tests with libc.a on x86_64 linux? >> >> we have a musl-gcc script when the compiler is gcc (it uses >> a simple spec file to set things up), i don't know what's >> the equivalent mechanism in clang world, but i think one >> can create a simple script based on the first version of >> musl-gcc >> >> http://git.musl-libc.org/cgit/musl/commit/?id=58f430c1e0255c0b28aed1e9bf3d892c18c06631 > > Do you mean the version removed in that commit? As long as you're just > building simple test files and not large program/library ecosystems, I > think it's even simpler than that. For static linking, just using > -nostdinc, -isystem, and -L should be all you need to compile/link > against the instrumented musl libc.a instead of the host libc. > Assuming the host is musl-based already, -nostdinc and -isystem > shouldn't even be needed. Just -L is sufficient. > >> the test system does not know about toolchain details >> the user has to provide whatever compiler wrapper script >> is needed to make things work >> >> but i think i wont try to integrate this into our libc-test >> right away, libc-test is designed to test a posix libc with >> minimal assumptions or external dependencies >> (the testing process of musl is not very formal or automated >> yet anyway) > > Indeed, I don't think fuzzing is something that belongs with regular > functionality/regression tests. It presumably takes a lot more time, > requires different build procedures, and addresses a different need > than the tests we have. > >> > > the question is how hard it is to do (1) ? >> > > >> > > i assume asan is non-trivial to set up for that (or is it >> > > enough to replace malloc calls? and some startup logic?) >> > >> > asan replaces malloc and a few more libc functions. >> > It works with various different libcs, so there is a good chance that >> > it will work here with no or minimal changes. >> >> ok i'll try it > > I would guess it works with no change for static linking, but some > changes might be needed for dynamic linking. I'm perfectly happy with > all the fuzzing being done with static linking anyway; I don't think > dynamic linking would have significant additional code paths whose > coverage need checking. sadly, asan does not support fully static linking. > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.