From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5689508667307741169==" MIME-Version: 1.0 From: Mark Wielaard To: elfutils-devel@lists.fedorahosted.org Subject: Re: Fuzzing elfutils Date: Fri, 05 Dec 2014 09:58:20 +0100 Message-ID: <1417769900.18974.25.camel@bordewijk.wildebeest.org> In-Reply-To: 5480E9DD.5000706@mccme.ru --===============5689508667307741169== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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). 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 :) > > 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. > [skip] > > I might be good to have a central place to store these results. > > The mailinglist seems a little problematic and we might miss/overlook > > some issues just posted to the list. > = > Sure, and mailing several megs of attachments to all the list is not = > nice too. It's just there is no info about bug reporting on the project = > page at https://fedorahosted.org/elfutils/ . Oops. Fixed! > > Do you have some location where you > > can store them and any future files? Or could you open a bugzilla report > > against elfutils and attach them there? > > https://bugzilla.redhat.com/enter_bug.cgi?product=3DFedora > = > I think the bugzilla is exactly fine for this. Filed here: > = > https://bugzilla.redhat.com/show_bug.cgi?id=3D1170810 Thanks! Mark --===============5689508667307741169==--