From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3234571812487254936==" MIME-Version: 1.0 From: Alexander Cherepanov To: elfutils-devel@lists.fedorahosted.org Subject: Re: Fuzzing elfutils Date: Fri, 05 Dec 2014 02:10:21 +0300 Message-ID: <5480E9DD.5000706@mccme.ru> In-Reply-To: 20141204142734.GA19050@bordewijk.redhat.com --===============3234571812487254936== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 2014-12-04 17:27, Mark Wielaard wrote: [skip] > BTW. It is helpful to know which architecture you are running on. Some > issues only show on a 32bit architecture trying to parse a 64bit ELF file, > or on little/big endian systems parsing a different endian ELF file. Yes, sorry, I'm using amd64 now. Maybe will switch to x86 later. >> I'm not very familiar with elfutils. Which commands give the most code >> coverage (and shortest run time)? I've used two commands so far: >> >> objdump -rs >> readelf -aAdehIlnrsSVcp -w >> >> and crashes seem to differ for them. > > That does give a biggest coverage. For eu-readelf -w you might want to use > -N, --numeric-addresses Do not find symbol names for addresses in DWARF d= ata > which can increase the runtime a lot (we really need to not do a linear > search to lookup the addresses...). Thanks for the tip! > But I found that using such broad coverage makes the search space for the > 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 data > 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). >> BTW does indended use of elfutils include the use against untrusted >> files and do you track corresponding security issues? > > I guess it isn't specifically intended for use against completely untrust= ed > files. But it happens of course. Also some of the elfutils libraries (lib= elf, > libdw) are used by tools that might process untrusted data. For example > systemd might use libdw to extract backtraces from core files - which sho= uld > normally be "trusted" because generated by the kernel, but there might be > bugs in the generation or they might refer to ELF or debug files that a > hostile user might have prepared. So we are actively working to make it > work robustly against anything thrown at it. Nice to hear it! > We don't specificly track any security issues, we just treat them as bugs > to be fixed and do a new release when enough/important bugs have been fix= ed. > 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. [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/ . > 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 -- = Alexander Cherepanov --===============3234571812487254936==--