From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3141779405748258373==" MIME-Version: 1.0 From: Mark Wielaard To: elfutils-devel@lists.fedorahosted.org Subject: Re: Fuzzing elfutils Date: Wed, 31 Dec 2014 12:03:51 +0100 Message-ID: <20141231110351.GA2897@blokker.redhat.com> In-Reply-To: 54A0C79D.4010506@mccme.ru --===============3141779405748258373== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Alexander, On Mon, Dec 29, 2014 at 06:16:45AM +0300, Alexander Cherepanov wrote: > We start with a bunch of samples. > = > The first step is to pick distinct bugs. You do it when you fix issues. > Let's assume for now that one commit =3D=3D one bug. Then for every bug... > = > It's nice to document who found the bug. This is useful for credit (and > hence for CVE assignment). > = > Even better to document in which bunch of samples (bugzilla attachment or > something) the bug was found. This useful as a date of disclosure (and he= nce > for CVE assignment). > = > Even better to document which specific sample triggered the bug. This mak= es > it possible to check if the fix is applied correctly. (Perhaps I can do it > for my samples automatically by retesting them against various commits.) So for issues found before elfutils 0.161 I think this is all a bit mixed up. We started out with a bunch of samples from Hano and you and then when I realized those samples showed both specific bugs and design issues that made those bugs worse I started fuzzing myself a bit to find more "patterns". And not all those "samples" were kept. For elfutils 0.161 there are about 80 patches that fix various issues found by the fuzzing examples. Some were more "fundemental" than others. The patches to fix the ELF header and data buffer reading/sanity checking in libelf, the leb128 parsing issues in libdw and the relocation fixes in libdwfl solve whole classes of bugs for example. Without those fixes the other bugs are far worse (because they make reading/writing memory outside the ELF image far easier). And I am afraid there are still some fundamental issues left see https://bugzilla.redhat.com/show_bug.cgi?id=3D1170810#c7 that really need to be fixed before we can claim any random sample thrown at elfutils shouldn't crash, hang or produce bogus results. The good news is that things seem to have improved a lot and it now takes hours/days to find new issues instead of minutes. But till we release 0.162 with at least those 3 fundamental issues fixed I think keeping strict track of one sample, one bug, one fix is not realistic. > Then we need to separate security bugs from non-security ones. To do it > precisely is difficult but it can be done roughly, e.g. overwriting a buf= fer > with attacker controlled data is probably a security issue while null > pointer dereference is probably not (for the usual use-case of elfutils a= s I > understand it; if elfutils is used as a library in a bigger program the > situation becomes more complex). > Some analysis can be performed automatically based on valgrind/gdb output > but I'm not sure how good it can be and I haven't yet implemented it. So, > for now, I'd like to say that it's up to a person who fixes the issue;-) Since I am the person fixing most issues I am afraid I don't keep track of whether something is a "security issue" or not. Making elfutils crash, hang or produce bogus/unreliable results are all pretty bad and just need to be fixed. Whether they are "exploitable" or not. In my experience any such issue can be made into a security issue with enough ingenuity. > Later some folks will want to backport the security fixes to the release = of > elfutils which they have in their distro. For this, they will need to know > if their version is affected. Your policy in this regard may vary from > backporting fixes yourself to saying that they just have to migrate to the > new version. Probably it's enough to check one reasonably old version (I = can > do it for my samples against version 0.152). If you can readily say that, > e.g., all versions are affected, even better. > I guess Red Hat / Fedora will also want to backport the fixes? Perhaps th= ey > have some guidelines for you to follow? I'll ask. For Fedora I just update the package to the latest upstream release as soon as possible to fix any bugs found between releases. = > Somewhere in the process CVEs can be requested. It seems, now, MITRE assi= gns > one CVE to a group of similar issues found by one person, disclosed in one > day and affecting the same versions. Hence all these pieces of data are > essential for a CVE request. > = > The priorities IMHO should be as follows. > = > 1. Pick which commits/fixes are for security issues. > = > 2. Everything else (without any order): > = > a) match fixes with samples (at least roughly: this patchset fixes issues > from this bunch of samples; but without mixing issues from different > researchers); > = > b) determining affected versions for each issue. > = > It seems I need at least to do some rechecking before requesting CVEs. WD= YT, > is it feasible/reasonable to work this out e.g. for issues from the last > month? To be honest, I don't think that is feasible. Just finding, analysing and fixing the issues found is a lot of work. I try to keep track of what/who originally triggered some fix. But certainly for fixes before the 0.161 release I don't think splitting them out and catogorizing them separately is very useful. You will need them all anyway. I think it is reasonable to just say that we are working towards making it safe to process arbitrary random ELF files and DWARF debuginfo data with elfutils by 0.162 (to be released on March). But that in general people should only use elfutils tools and libraries on files produced by a trusted toolchain for now. I do realize parsing ELF and DWARF files with elfutils tools will show up in surprising places and that people cannot always make sure they files processed are generated by a trusted toolchain and aren't malicious. Which is why I take your reports very seriously. I am certainly not against filing CVE requests and trying to figure out exactly what security issue is fixed by which patch. But realisticly there are just too many issues at the moment. Practically I won't be able to help much the next couple of weeks because I don't have stable access to the internet on vacation. But I'll try and monitor any new issues found. Thanks, Mark --===============3141779405748258373==--