From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7242 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 23:05:13 -0700 Message-ID: References: <20150321002616.GF16260@port70.net> <20150321004637.GQ23507@brightrain.aerifal.cx> <20150321010043.GR23507@brightrain.aerifal.cx> <20150321013225.GT23507@brightrain.aerifal.cx> <20150321015619.GU23507@brightrain.aerifal.cx> <20150321022023.GW23507@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 1426917952 2108 80.91.229.3 (21 Mar 2015 06:05:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 06:05:52 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-7255-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 21 07:05: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 1YZCXc-0004MF-96 for gllmg-musl@m.gmane.org; Sat, 21 Mar 2015 07:05:48 +0100 Original-Received: (qmail 30125 invoked by uid 550); 21 Mar 2015 06:05:46 -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 30104 invoked from network); 21 Mar 2015 06:05:45 -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=bR/HZ9Ij8u2hGMEOAFYHvp0Wx73Pi16SA+5fOXMhnss=; b=PXnDPZwlc3WmiZ/WgQXOLHmUILAeu+/bfRRaf9beZkcN4cR0iqrB0YRykxi9BznMC0 cSlq3XsR636PF2mYRsob3zbKXSVEQ+zY00aUki809qoG8TY8mfwGHTGxjA11jo5n57NY xBA0VMazh/3ixHWk90zvzrDPmd4K/h9U8j4jwGyDXeM8msSU3quhkaEnE6pCKuSBL/JJ 0740hcFmIfC4tNVh3Y/VW2mcMziJMD6BfyzoGgVeuwxM9+R52x4vwnyhyp07sqNKS+i7 v60OM21NWGYUtKOFUu74aZ3kyGEO59mrL78zXtrYsAQSZb6DCbwu3JSvTBp3/tZnvQDB c/HA== X-Received: by 10.52.104.105 with SMTP id gd9mr77073365vdb.76.1426917933474; Fri, 20 Mar 2015 23:05:33 -0700 (PDT) In-Reply-To: <20150321022023.GW23507@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7242 Archived-At: On Fri, Mar 20, 2015 at 7:20 PM, Rich Felker wrote: > On Fri, Mar 20, 2015 at 07:14:33PM -0700, Konstantin Serebryany wrote: >> > >> > Sorry to keep bombarding you with questions. >> >> You are more than welcome! >> >> > 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? >> >> I think it can with a reasonable additional work, but not out of the box. >> The compiler instrumentation in clang clearly does not care about >> dynamic vs static linking. >> If you build the source with "-fsanitize=leak -fsanitize-coverage=4 >> -O1" the compiler will not insert any of the asan instrumentation >> and only insert calls to a couple of functions needed for coverage. >> Then, instead of linking with the full asan+coverage run-time, you >> will need a very simple re-implementation of coverage-only runtime. > > Could the existing runtime be used, just stripped down? Yes, but for the basic functionality needed by the fuzzer it's simpler to write it from scratch, see below: ======================================================== svn co http://llvm.org/svn/llvm-project/llvm/trunk/lib/Fuzzer cat <cov-minimal-rt.c static long counter; void __sanitizer_cov_with_check(int *guard) { if (*guard == 0) { counter++; *guard=1; } } long __sanitizer_get_total_unique_coverage() { return counter; } void __sanitizer_cov_module_init() {} void __sanitizer_reset_coverage(){} void __sanitizer_get_coverage_guards(){} void __sanitizer_get_number_of_counters(){} void __sanitizer_update_counter_bitset_and_clear_counters(){} void __sanitizer_set_death_callback(){} EOF clang -std=c++11 -c Fuzzer/Fuzzer*.cpp -I Fuzzer clang -std=c++11 -fsanitize=leak -fsanitize-coverage=3 -mllvm -sanitizer-coverage-block-threshold=0 Fuzzer/test/SimpleTest.cpp -c clang -c cov-minimal-rt.c clang++ *.o ./a.out ======================================================== Seed: 1285924057 Shuffle: Size: 1 prefer small: 1 #1 cov: 5 bits: 0 exec/s: 0 Shuffle done: 1 IC: 5 #2 cov: 7 bits: 0 exec/s: 0 #2 NEW: 7 B: 0 L: 64 S: 2 I: 0 #4 cov: 7 bits: 0 exec/s: 0 #8 cov: 7 bits: 0 exec/s: 0 #16 cov: 7 bits: 0 exec/s: 0 #32 cov: 7 bits: 0 exec/s: 0 #64 cov: 7 bits: 0 exec/s: 0 #128 cov: 7 bits: 0 exec/s: 0 #256 cov: 7 bits: 0 exec/s: 0 #512 cov: 7 bits: 0 exec/s: 0 #1024 cov: 7 bits: 0 exec/s: 0 #2048 cov: 7 bits: 0 exec/s: 0 #2107 NEW: 11 B: 0 L: 64 S: 3 I: 0 #2153 NEW: 12 B: 0 L: 1 S: 4 I: 1 H 1: 72 #4096 cov: 12 bits: 0 exec/s: 0 #8192 cov: 12 bits: 0 exec/s: 0 #16384 cov: 12 bits: 0 exec/s: 0 #18091 NEW: 15 B: 0 L: 2 S: 5 I: 4 Hi 2: 72 105 #18122 NEW: 17 B: 0 L: 4 S: 6 I: 0 Hi?i 4: 72 105 8 105 Found the target, exiting The recently added afl-style counters (https://code.google.com/p/address-sanitizer/wiki/AsanCoverage#Coverage_counters) are a bit more involved, but the basic bool-per-edge is quite enough in most cases. The fuzzer itself is written in C++ and uses STL (probably, not the best idea, but it makes the experiments simpler). Can't tell if it will be a problem with musl, but after all the fuzzer itself is also trivial (as well as the entire concept) > >> But, my previous experience with running fuzzers w/o memory bug >> detectors (asan, or others) >> suggests that this is a bad idea. Memory bugs tend to accumulate and >> show up in the following iterations (if at all). > > Well static linking with musl does not impose any constraint on > redefining functions, so you could easily use a debugging malloc that > lines up each allocation to end on a page boundary with a guard page > after it. Yea... This will slowdown fuzzing and guard pages only protect you from overflow in one direction (ether left, of right, but not both). But this is better than nothing. > This would of course be slow and use lots of memory but > would catch all heap overflows. And -fstack-protector-all would catch > most stack-based overflows. Only stack-overflow-write by a small amount, but yes, better than nothing. BTW, writing a minimalistic asan run-time as part of musl should be a matter of a couple of hours. Probably much faster than making the current monster work with static linking. I'd be happy to help with such. --kcc