From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7692171551583217830==" MIME-Version: 1.0 From: Alexander Cherepanov To: elfutils-devel@lists.fedorahosted.org Subject: Re: Fuzzing elfutils Date: Mon, 29 Dec 2014 06:16:45 +0300 Message-ID: <54A0C79D.4010506@mccme.ru> In-Reply-To: 1417769900.18974.25.camel@bordewijk.wildebeest.org --===============7692171551583217830== 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: >>> 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. Sorry for the late reply. Unfortunately I don't have complete answers = but let's try to reason about it. Kinda thinking out loud:-) 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 hence for CVE assignment). Even better to document which specific sample triggered the bug. This = makes 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.) 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 = buffer with attacker controlled data is probably a security issue while = null pointer dereference is probably not (for the usual use-case of = elfutils as 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;-) 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 = they have some guidelines for you to follow? Somewhere in the process CVEs can be requested. It seems, now, MITRE = assigns 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. = WDYT, is it feasible/reasonable to work this out e.g. for issues from = the last month? Please note that what is written here is my personal (and quite rough) = take on the subject. The usual link for requesting CVEs for Open source = software is this: https://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html -- = Alexander Cherepanov --===============7692171551583217830==--