From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7228 Path: news.gmane.org!not-for-mail From: Rich Felker 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 20:46:37 -0400 Message-ID: <20150321004637.GQ23507@brightrain.aerifal.cx> References: <20150320235227.GE16260@port70.net> <20150321002616.GF16260@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426898828 5327 80.91.229.3 (21 Mar 2015 00:47:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 00:47:08 +0000 (UTC) To: musl@lists.openwall.com, Konstantin Serebryany Original-X-From: musl-return-7241-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 21 01:46:56 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 1YZ7Yz-0002WH-7Y for gllmg-musl@m.gmane.org; Sat, 21 Mar 2015 01:46:53 +0100 Original-Received: (qmail 1726 invoked by uid 550); 21 Mar 2015 00:46:51 -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 1708 invoked from network); 21 Mar 2015 00:46:51 -0000 Content-Disposition: inline In-Reply-To: <20150321002616.GF16260@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7228 Archived-At: On Sat, Mar 21, 2015 at 01:26:16AM +0100, Szabolcs Nagy wrote: > * Konstantin Serebryany [2015-03-20 17:06:18 -0700]: > > On Fri, Mar 20, 2015 at 4:52 PM, Szabolcs Nagy wrote: > > > * Konstantin Serebryany [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