[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150321004637.GQ23507@brightrain.aerifal.cx>
Date: Fri, 20 Mar 2015 20:46:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com,
Konstantin Serebryany <konstantin.s.serebryany@...il.com>
Subject: Re: buffer overflow in regcomp and a way to find more of those
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.
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.
