‘guix lint’ CVE checker

‘guix lint’ CVE checker

[Ludovic Courtès]

Hi!

Commit 5432734 adds a ‘cve’ checker for ‘guix lint’.  It fetches the CVE
database from NIST, matches package names/versions against those found
in CVEs, and reports CVE IDs:

--8<---------------cut here---------------start------------->8---
$ time GUIX_PACKAGE_PATH= ./pre-inst-env guix lint -c cve
gnu/packages/gcc.scm:324:2: gcc-4.9.3: probably vulnerable to CVE-2015-5276
gnu/packages/image.scm:708:2: jasper-1.900.1: probably vulnerable to CVE-2008-3522
gnu/packages/pulseaudio.scm:44:2: libsndfile-1.0.25: probably vulnerable to CVE-2015-7805
gnu/packages/xml.scm:64:2: libxml2-2.9.2: probably vulnerable to CVE-2015-7941, CVE-2015-7942
gnu/packages/xml.scm:144:2: libxslt-1.1.28: probably vulnerable to CVE-2015-7995

real	0m2.669s
user	0m2.248s
sys	0m0.120s
--8<---------------cut here---------------end--------------->8---

The libxml2/libxslt issues are actually patched, but since we didn’t
change the version number, the tool assumes that our packages are
vulnerable.  We should change version numbers in the future when
patching vulnerabilities.

One limitation is that package names may differ between CVEs and what we
have.  There’s a tentative ‘package-name->cpe-name’ conversion procedure
that currently handles one case, but we should augment it as we notice
new cases.

Thoughts?

Ludo’.

Re: ‘guix lint’ CVE checker

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> The libxml2/libxslt issues are actually patched, but since we didn’t
> change the version number, the tool assumes that our packages are
> vulnerable.  We should change version numbers in the future when
> patching vulnerabilities.

Alternately, ‘lint’ could check the package’s patches and silence the
warning if there are patches whose name contain the offending CVE ID.

That way it would still catch vulnerabilities later reported for that
version.

Thoughts?

Ludo’.

Re: ‘guix lint’ CVE checker

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> The libxml2/libxslt issues are actually patched, but since we didn’t
>> change the version number, the tool assumes that our packages are
>> vulnerable.  We should change version numbers in the future when
>> patching vulnerabilities.
>
> Alternately, ‘lint’ could check the package’s patches and silence the
> warning if there are patches whose name contain the offending CVE ID.

Yes, I think this is the right approach.

If changing the version number effectively disables this entire
mechanism, that seems like an inferior approach, because if more CVEs
are later discovered, we won't be notified, iiuc.  Is that right?

     Thanks,
       Mark

> That way it would still catch vulnerabilities later reported for that
> version.
>
> Thoughts?
>
> Ludo’.

Re: ‘guix lint’ CVE checker

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> gnu/packages/gcc.scm:324:2: gcc-4.9.3: probably vulnerable to CVE-2015-5276
> gnu/packages/image.scm:708:2: jasper-1.900.1: probably vulnerable to CVE-2008-3522
> gnu/packages/pulseaudio.scm:44:2: libsndfile-1.0.25: probably vulnerable to CVE-2015-7805
> gnu/packages/xml.scm:64:2: libxml2-2.9.2: probably vulnerable to CVE-2015-7941, CVE-2015-7942
> gnu/packages/xml.scm:144:2: libxslt-1.1.28: probably vulnerable to CVE-2015-7995

Interestingly, the GCC and libxslt ones are no longer visible at
<https://nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-Modified.xml.gz>.
I wonder if there’s an eviction policy, but I don’t see it mentioned.

Ideas?

Ludo’.

Re: ‘guix lint’ CVE checker

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> The libxml2/libxslt issues are actually patched, but since we didn’t
>>> change the version number, the tool assumes that our packages are
>>> vulnerable.  We should change version numbers in the future when
>>> patching vulnerabilities.
>>
>> Alternately, ‘lint’ could check the package’s patches and silence the
>> warning if there are patches whose name contain the offending CVE ID.
>
> Yes, I think this is the right approach.

Done in 4e70fe4.

> If changing the version number effectively disables this entire
> mechanism, that seems like an inferior approach, because if more CVEs
> are later discovered, we won't be notified, iiuc.  Is that right?

Correct.

Thanks,
Ludo’.