From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7225 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: buffer overflow in regcomp and a way to find more of those Date: Sat, 21 Mar 2015 00:52:27 +0100 Message-ID: <20150320235227.GE16260@port70.net> References: 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 1426895579 23870 80.91.229.3 (20 Mar 2015 23:52:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Mar 2015 23:52:59 +0000 (UTC) Cc: musl@lists.openwall.com To: Konstantin Serebryany Original-X-From: musl-return-7238-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 21 00:52:49 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 1YZ6iX-0001qb-71 for gllmg-musl@m.gmane.org; Sat, 21 Mar 2015 00:52:41 +0100 Original-Received: (qmail 8074 invoked by uid 550); 20 Mar 2015 23:52:40 -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 8050 invoked from network); 20 Mar 2015 23:52:39 -0000 Mail-Followup-To: Konstantin Serebryany , musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7225 Archived-At: * 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. (2) the other approach is to cut parts of the libc out (the parsers often don't depend on too much libc internals) and build them with whatever runtime the fuzzer needs 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?) at first it is ok if the fuzzer only catches crashing bugs so if that's easy to do i'd go for that. for (1) i can write the test cases and adjust the musl build system, but i dont know how much difficulty should i expect thanks