[arch-security] CVEs in Arch Linux (current, future tracking)

[Ikey Doherty]

To provide a shorter response: I'm in no way saying its the only
tool to use, its just one part of a process. I'm also not saying
we're going to rely solely on NVD in the future, hence my comment
regarding "increase the amount of information", i.e. we would
monitor multiple sources within cve-check-tool, and cve-check-tool
is just one part of a set of tools.

Regardless, this topic derailed quickly, I simply provided you
with a means and a set of potential CVEs - my main interest is
if someone intends to look into the patch naming situation.
I don't use Arch Linux myself so wouldn't be the one to be
able to implement it without assistance.

- ikey

On 16/04/15 00:32, Levente Polyak wrote:
>> So cve-check-tool deals solely with non-embargoed CVEs, and as such
>> the CVEs known to distributions are handled differently. An example
>> of this is the recent openssl updates, whereby the CVE was marked
>> as "reserved" for a fair amount of time. This is naturally because
>> these are high publicity projects, and it gives everyone plenty of time to
>> migrate.
>>
>> We've already got a few things being worked on at the moment to
>> monitor these hi-p projects to increase the amount of information
>> available to cve-check-tool at any one time.
>>
>> Note for relatively normal CVEs (99% of them) they appear rapidly
>> within the DB, and we index/check every vuln from 2002 up to the
>> current minute (NVD is resynced every 3-4hr)
>
>
> No, its simply not true! It lacks behind often a lot, even for non
> embargoed and publicly disclosed vulnerabilities which often even have
> PoCs attached. Even for initially embargoed CVEs after the vendor
> releases a own advisory its still unavailable after multiple months.
>
> Most of the time if we write advisories for Arch Linux then we have to
> point to Red-Hat or mitre as the NVD does not contain the CVE yet (and
> most of the time that has nothing to do with embargoed CVEs like the
> openssl case) as those were disclosed on public lists with full details
> and CVE IDs were assigned by mitre.
> During distribution level of mitigation we experience over and over
> again that NVD is hanging behind for some non-embargoed CVEs for days,
> weeks and sometimes moths.
>
> You can check our CVE page [0] or the released advisories [1], if at the
> point we write an advisory the NVD contains the CVE already, we are
> always using that as a reference link. If its not available then we use
> something different, please note how often some other links are used to
> that particular point of time (also several of the non embargoed CVEs on
> the CVE [0] page do *still* not have a association in NVD!
>
> After a fast 5min search just to name some, which are disclosed for a
> very long time and still have no entry in NVD:
> - icecast: CVE-2015-3026
> - tor: CVE-2015-2928 CVE-2015-2929
> - musl: CVE-2015-1817
> - webkitgtk: CVE-2015-2330
> - sudo: CVE-2014-9680
> - ntp: CVE-2014-9297 CVE-2014-9298
> - postgresql: CVE-2014-8161 CVE-2015-0241 CVE-2015-0243 CVE-2015-0244
>
>
> Don't get me wrong, your tool is great and useful, but trust me, only
> monitoring NVD for a distribution level of mitigation is *very* far from
> being optimal, enough or up-to-date (also when monitoring some of the
> "hi-p projects"). Please don't take this as offense.
>
> cheers,
> Levente
>
> [0] https://wiki.archlinux.org/index.php/CVE
> [1] https://wiki.archlinux.org/index.php/Security_Advisories
>