Re: buffer overflow in regcomp and a way to find more of those

[Konstantin Serebryany <konstantin.s.serebryany@gmail.com>]

On Fri, Mar 20, 2015 at 5:46 PM, Rich Felker <dalias@libc.org> wrote:
> On Sat, Mar 21, 2015 at 01:26:16AM +0100, Szabolcs Nagy wrote:
>> * Konstantin Serebryany <konstantin.s.serebryany@gmail.com> [2015-03-20 17:06:18 -0700]:
>> > On Fri, Mar 20, 2015 at 4:52 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>> > > * Konstantin Serebryany <konstantin.s.serebryany@gmail.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