This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Fuzzing elfutils
- From: Alexander Cherepanov <cherepan at mccme dot ru>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 29 Dec 2014 06:16:45 +0300
- Subject: Re: Fuzzing elfutils
On 2014-12-05 11:58, Mark Wielaard wrote:
>>> 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 fixed.
>>> 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 == 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