Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Sep 2017 14:40:44 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Linux kernel CVEs not mentioned on oss-security

On Tue, 26 Sep 2017, Kurt Seifried wrote:

> On Tue, Sep 26, 2017 at 11:31 AM, Bob Friesenhahn <
>>
>> It is incredibly difficult for most non-commercial upstreams to do this
>> since they have limited manpower, they are not informed of all the
>> applicable CVEs, and the CVE information received is essentially hearsay,
>> received from unknown/unverifiable sources.  I am thinking that it is best
>> for most non-commercial upstreams to not mention CVEs at all.
>>
>
> Uhm. Where to begin. Ok, well for one thing just because we can't have 100%
> perfect coverage doesn't mean we should simply give up. Also CVE's aren't
> "hearsay", they are claims based, with evidence being needed (the stronger
> the claim, the more likely you are to get a CVE), especially in the open
> source world where I typically require a link to either the vuln code, or
> the code patch in order to give a CVE to something (if you can't tell me
> what code is vuln, in open source, then chances are you need to understand
> the vuln more before we CVE it up, exceptions of course can be made, e.g.
> when someone has a reproducer that works reliably).

I did not mean that the CVE itself is "hearsay".  What I meant is the 
way an upstream maintainer is informed about a CVE is often no better 
than "hearsay".  In some cases the information comes from someone who 
is already known and trusted while in other cases it is impossible to 
even tell who is providing the information since the person providing 
the information has intentionally obfusticated their identity.

If an upstream maintainer reports that a release resolves a particular 
CVE, then he could easily have provided wrong information given that 
the upstream maintainer does not have access to the technical details 
of the report and analysis which initiated the CVE and may confuse one 
issue with another.

It may be that the upstream maintainer fixes a problem and some weeks 
later the CVE is created related to the problem which was fixed.

> You can check the CVE Database? There is the official MITRE one:
> cve.mitre.org and the DWF for Open Source (and yes, I lag in submissions to
> MITRE) at https://github.com/distributedweaknessfiling/DWF-CVE-Database/ in
> both cases the CVEs will have reference link(s) that ideally point to the
> upstream making it easy to match up.

The database entries do not contain enough information for an upstream 
maintainer to identify one issue from another similar issue.  They 
only contain sanitized information.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.