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