[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.GSO.2.20.1709261422390.12755@scrappy.simplesystems.org>
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.
