From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1569268663468901770==" MIME-Version: 1.0 From: Alexander Cherepanov To: elfutils-devel@lists.fedorahosted.org Subject: Re: Fuzzing elfutils Date: Mon, 08 Dec 2014 06:06:13 +0300 Message-ID: <548515A5.7080304@mccme.ru> In-Reply-To: 1417769900.18974.25.camel@bordewijk.wildebeest.org --===============1569268663468901770== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 2014-12-05 11:58, Mark Wielaard wrote: > On Fri, 2014-12-05 at 02:10 +0300, Alexander Cherepanov wrote: >> On 2014-12-04 17:27, Mark Wielaard wrote: >>> But I found that using such broad coverage makes the search space for t= he >>> fuzzer really, really big. It can take days for the fuzzer to generate a >>> somewhat valid data for some of the section types. It is imho better to >>> not use -a or -w, or a combination of flags for different headers or da= ta >>> sections, but to create a minimal valid ELF file with just one kind of >>> section or segment and then let the fuzzer run on that with just one >>> specific flag (or --debug-dump=3Dxxx). >> >> I think this is specific to AFL which you seem to use. For it, I agree >> with your approach. But I'm not sure how useful such an advanced fuzzer >> at this stage. I'm still using zzuf. Right now it gives more crashes >> than I can pipe through valgrind. You can get similar behavior with AFL >> if you specify -dn options (or perhaps you can use just -d). > > Yes, that is true. I have been using afl. And it is good to throw some > other fuzzers at it. The reason you are so successful is because till > now we concentrated on readelf and libelf. Clearly the other tools need > fuzzing too. And we do know debuginfo (-w), libdw, has some known > issues. One of which I just fixed in response to your testcases (see the > patch posted, I haven't pushed it yet, to see if there are any > comments). Ok, I've switched to mjw/pending branch. I hope it's the right branch to = have all your latest fixes? > I hope to get to the other main libdw debug issue (leb128 > parsing) soon. After that hopefully you will have a bit more of a > challenge :) Well, I've uploaded some more crashes for the current (i.e. mjw/pending) = readelf. Some of them could be duplicates of the previous unfixed ones. >>> We don't specificly track any security issues, we just treat them as bu= gs >>> to be fixed and do a new release when enough/important bugs have been f= ixed. >>> There have been people who have filed CVEs against elfutil bugs though. >>> I don't have any experience with filing CVEs though. >> >> I see. For now, I've added 'Security' keyword to the bug in the >> bugzilla. This should get attention of the security team. Otherwise I >> can ask for CVEs later in oss-security mailing list. > > Thanks, some guidance on how to deal with these issues would be > appreciated. Sadly at the moment there are just too many to special case > them. So for now just report issues and we try to fix them asap. > > The short term plan is to do a new release (elfutils 0.161) after the > next weekend. Get as many bugs fixed before Friday 12th, do some > additional testing during the weekend and have a release the 15th. This > is not a very special release, just our periodic ~3/4 month release > cycle. It will have a lot of robustness fixes though. But I doubt we > will have fixed all crashers found by then. We will try though. I'll reply to this a bit later. -- = Alexander Cherepanov --===============1569268663468901770==--