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

[Rich Felker <dalias@libc.org>]

On Fri, Mar 20, 2015 at 06:37:39PM -0700, Konstantin Serebryany wrote:
> On Fri, Mar 20, 2015 at 6:32 PM, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Mar 20, 2015 at 06:05:04PM -0700, Konstantin Serebryany wrote:
> >> On Fri, Mar 20, 2015 at 6:00 PM, Rich Felker <dalias@libc.org> wrote:
> >> > On Fri, Mar 20, 2015 at 05:54:49PM -0700, Konstantin Serebryany wrote:
> >> >> >> > > 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.
> >> >
> >> > Is this just an oversight or something fundamental that's hard to fix?
> >>
> >> Quite fundamental.
> >> asan needs to be able to intercept certain libc functions and on all
> >> platforms (linux, android, OSX, Windows, etc) it works only when libc
> >> itself is dynamically linked.
> >
> > But if you're compiling libc itself with asan, couldn't it just
> > hard-insert the interception code into the implementations of these
> > functions during compiling?
> 
> I think it could, it's just quite a bit of work to do. :(
> We may end up doing it eventually as I hope to use instrumented glibc
> whenever we can,
> and at that point intercepting functions from glibc will become rather
> silly. But we are not there yet.

Sorry to keep bombarding you with questions. One more: is it only asan
that needs dynamic linking? If we're willing to drop asan for now and
just rely on musl itself crashing for heap corruption (musl does a
good job of detecting it usually), can the necessary coverage stuff
still work with static linking?

Rich