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

[Ikey Doherty]

On 15/04/15 23:06, Levente Polyak wrote:
> Hey Ikey,
>
> On 04/15/2015 09:18 PM, Ikey Doherty wrote:
>> Today I added initial PKGBUILD support to cve-check-tool [1],
>> an automated CVE checking tool that works with the NVD
>> Database, matching versions, etc, with a given source
>> repository.
>
> Nice tool, looks really useful as an additional way to start tracking
> affected packages that are sometimes otherwise missed. Unfortunately NVD
> is often really heavily lacking behind so for aprox. half of the
> actively mitigated packages there do not have assigned CVEs in the NVD
> yet, but thats a different story :)

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)

> I think it makes really sense if I add your tool as an additional
> automated CVE input source to the web-tracker that I'm developing for
> the package mitigation process.
>

Ideally we want to make the tool adaptable as possible for use in
multiple distributions.

>>
>> Currently patch detection is very flaky, as there doesn't
>> appear to be a consistent naming for CVE patches within
>> Arch Linux. I would appreciate if someone could work with
>> me to improve the patch detection within cve-check-tool,
>> or work towards patch name standardisation within Arch
>> Linux.
>
> Yep thats true. Patch detection currently looks very simple, I'm aware
> of several packages that are having patches that fall out of this scheme.
> To name some: some patches have a postfix (or suffix), something like
> -overflow or similar. Others are a combination of two or more CVE IDs in
> a single filename and then there are also some that just have "random"
> names describing what type its fixing rather then any relation to the CVE.
> Patch name standardization for security related patches in Arch will not
> be that easy as it's up to the maintainers, but at least I will start a
> small chat/discussion round to speak about this topic.

It would be interesting to see where this leads to. The ability to
instantly know the security/patch status of a distribution is very
handy imo.

>
>>
>> Below is an initial list of CVEs I cannot determine are
>> actually patched (by  manually looking) - so some of them
>> are potentially false positives.
>
> Thank you, its really appreciated. I will have a deep look into those in
> the following days including a integral verification that those are
> affected to start mitigation. I have already made a rough look and at
> least I can clear out some of the false-positives that i have
> re-verified right now:
>
> glibc: CVE-2014-7817 (ensured its fixed in 2.21 via source, NVD fix
> version is wrong, notice [0])
> cpio: CVE-2015-1197
> vorbis-tools: CVE-2014-9638 CVE-2014-9640
> unzip: CVE-2014-9636
>
> cheers
> Levente
>

Thanks
- ikey

> [0]
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=a39208bd7
>