[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Mar 2015 21:32:25 -0400
From: Rich Felker <dalias@...c.org>
To: Konstantin Serebryany <konstantin.s.serebryany@...il.com>
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 06:05:04PM -0700, Konstantin Serebryany wrote:
> On Fri, Mar 20, 2015 at 6:00 PM, Rich Felker <dalias@...c.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?
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.
