From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7236 Path: news.gmane.org!not-for-mail From: Konstantin Serebryany Newsgroups: gmane.linux.lib.musl.general Subject: Re: buffer overflow in regcomp and a way to find more of those Date: Fri, 20 Mar 2015 18:37:39 -0700 Message-ID: References: <20150320235227.GE16260@port70.net> <20150321002616.GF16260@port70.net> <20150321004637.GQ23507@brightrain.aerifal.cx> <20150321010043.GR23507@brightrain.aerifal.cx> <20150321013225.GT23507@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1426901899 15091 80.91.229.3 (21 Mar 2015 01:38:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 01:38:19 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-7249-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 21 02:38:16 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YZ8Mg-0001MQ-MF for gllmg-musl@m.gmane.org; Sat, 21 Mar 2015 02:38:14 +0100 Original-Received: (qmail 29999 invoked by uid 550); 21 Mar 2015 01:38:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29972 invoked from network); 21 Mar 2015 01:38:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sDaWTrKvE07D3Io/ssCiOI/4zg/MuD+hyzOQ7Umqn7M=; b=NkCedO9jafSFbi7oy5g00Jj65nmdWtbvT2dsQKStlTWGr3t07AZDlIT/pwAqGiRetC dscKzD33rRf36hNcWGgryS3uiEWgTmZ/SqUx9smpeD+EmKtTkK7Y6qGyDPGKxzo8uyzJ ek3cOk49H5Yc95s/PbYISGMPd1uXFcRPFA3kOcoyTZ+eiuVfs+yCHrk/OJRSDzZQp4pQ s6goxHIoS7nmodLckcdHN75urETfWGLkClxz2x6UlVGqMVQVp9iWye9rC1fWpKDTcQuR tfn+uwvY+ewNsVN3akCpyA7GASWNgbAEEGBhKpcNjma0pzC0vGnlJsXDwjqm/agawhzH UNig== X-Received: by 10.52.104.105 with SMTP id gd9mr75786643vdb.76.1426901880419; Fri, 20 Mar 2015 18:38:00 -0700 (PDT) In-Reply-To: <20150321013225.GT23507@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7236 Archived-At: On Fri, Mar 20, 2015 at 6:32 PM, Rich Felker 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 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. > > Rich