Re: Dealing with CVEs that apply to unspecified package versions

[Ludovic Courtès]

Leo Famulari <address@hidden> skribis:

> On Mon, Mar 06, 2017 at 10:36:48PM +0100, Ludovic Courtès wrote:
>> Unfortunately, there’s no way to know whether such CVEs are actually
>> fixed at a specific package version or not, and they’re not uncommon.
>> Consequently, ‘guix lint -c cve’ would now report old CVEs that possibly
>> no longer apply to our package versions.
>
> I didn't notice any change in what the CVE checker reports after
> applying the diff. Did I miss a step?

You need to first clear your cache:

  rm -rf ~/.cache/guix/cve

Here’s the before/after diff I get:

--- /home/ludo/src/guix/cve-before.txt  2017-03-11 12:01:57.908151863 +0100
+++ /home/ludo/src/guix/cve-after.txt   2017-03-11 12:04:24.283399193 +0100
@@ -1,20 +1,42 @@
+gnu/packages/tls.scm:218:2: address@hidden: probably vulnerable to 
CVE-2014-3467, CVE-2014-3468, CVE-2014-3469
 gnu/packages/backup.scm:186:2: address@hidden: probably vulnerable to 
CVE-2016-8687, CVE-2016-8688, CVE-2016-8689
-gnu/packages/base.scm:754:2: address@hidden: probably vulnerable to 
CVE-2016-3075, CVE-2016-5417
-gnu/packages/base.scm:502:2: address@hidden: probably vulnerable to 
CVE-2016-6323
-gnu/packages/base.scm:788:2: address@hidden: probably vulnerable to 
CVE-2015-1781, CVE-2015-7547, CVE-2014-7817, CVE-2014-8121
+gnu/packages/base.scm:278:2: address@hidden: probably vulnerable to 
CVE-2014-9471
+gnu/packages/base.scm:767:2: address@hidden: probably vulnerable to 
CVE-2016-3706, CVE-2016-4429, CVE-2015-7547, CVE-2015-8776, CVE-2015-8777, 
CVE-2015-8778, CVE-2015-8779, CVE-2014-5119, CVE-2014-9761
+gnu/packages/base.scm:789:2: address@hidden: probably vulnerable to 
CVE-2016-3706, CVE-2016-4429, CVE-2015-1781, CVE-2015-7547, CVE-2014-5119, 
CVE-2014-7817, CVE-2014-8121
 gnu/packages/base.scm:155:2: address@hidden: probably vulnerable to 
CVE-2016-6321
-gnu/packages/base.scm:766:2: address@hidden: probably vulnerable to 
CVE-2015-7547, CVE-2015-8776, CVE-2015-8777, CVE-2015-8778, CVE-2015-8779, 
CVE-2014-9761
+gnu/packages/base.scm:503:2: address@hidden: probably vulnerable to 
CVE-2016-3706, CVE-2016-4429, CVE-2016-6323, CVE-2014-5119
+gnu/packages/base.scm:755:2: address@hidden: probably vulnerable to 
CVE-2016-3075, CVE-2016-3706, CVE-2016-4429, CVE-2016-5417, CVE-2014-5119
+gnu/packages/bash.scm:269:2: address@hidden: probably vulnerable to 
CVE-2016-9401
+gnu/packages/busybox.scm:31:2: address@hidden: probably vulnerable to 
CVE-2016-6301
 gnu/packages/compression.scm:210:4: address@hidden: probably vulnerable to 
CVE-2016-3189
-gnu/packages/image.scm:296:2: address@hidden: probably vulnerable to 
CVE-2017-5563, CVE-2016-10095
-gnu/packages/image.scm:487:2: address@hidden: probably vulnerable to 
CVE-2016-9112, CVE-2016-9113, CVE-2016-9114, CVE-2016-9115, CVE-2016-9116, 
CVE-2016-9117, CVE-2016-9118
+gnu/packages/databases.scm:329:2: address@hidden: probably vulnerable to 
CVE-2016-6664
+gnu/packages/databases.scm:720:2: address@hidden: probably vulnerable to 
CVE-2015-3717
+gnu/packages/databases.scm:254:2: address@hidden: probably vulnerable to 
CVE-2014-0001
+gnu/packages/databases.scm:666:2: address@hidden: probably vulnerable to 
CVE-2015-3717
+gnu/packages/gcc.scm:410:2: address@hidden: probably vulnerable to 
CVE-2016-2226, CVE-2016-4487, CVE-2016-4488, CVE-2016-4489, CVE-2016-4490, 
CVE-2016-4491, CVE-2016-4492, CVE-2016-4493
+gnu/packages/ghostscript.scm:64:2: address@hidden: probably vulnerable to 
CVE-2016-10165
+gnu/packages/gnome.scm:5393:4: address@hidden: probably vulnerable to 
CVE-2015-2785
+gnu/packages/gstreamer.scm:99:2: address@hidden: probably vulnerable to 
CVE-2017-5847, CVE-2017-5848, CVE-2016-9446
+gnu/packages/image.scm:487:2: address@hidden: probably vulnerable to 
CVE-2016-7163, CVE-2016-9112, CVE-2016-9113, CVE-2016-9114, CVE-2016-9115, 
CVE-2016-9116, CVE-2016-9117, CVE-2016-9118, CVE-2016-9675
+gnu/packages/image.scm:296:2: address@hidden: probably vulnerable to 
CVE-2017-5563, CVE-2016-10095, CVE-2016-9453, CVE-2015-8781, CVE-2015-8782, 
CVE-2015-8783, CVE-2015-8784
+gnu/packages/image.scm:505:2: address@hidden: probably vulnerable to 
CVE-2016-7163, CVE-2016-9675
+gnu/packages/linux.scm:3063:2: address@hidden: probably vulnerable to 
CVE-2016-1572
+gnu/packages/lynx.scm:35:2: address@hidden: probably vulnerable to 
CVE-2016-9179
 gnu/packages/mail.scm:1081:2: address@hidden: probably vulnerable to 
CVE-2016-8652
 gnu/packages/monitoring.scm:34:2: address@hidden: probably vulnerable to 
CVE-2016-10089
 gnu/packages/mp3.scm:231:2: address@hidden: probably vulnerable to 
CVE-2017-5665
 gnu/packages/mp3.scm:264:2: address@hidden: probably vulnerable to 
CVE-2017-5666, CVE-2017-5851
+gnu/packages/openldap.scm:36:2: address@hidden: probably vulnerable to 
CVE-2015-3276
 gnu/packages/perl.scm:50:2: address@hidden: probably vulnerable to 
CVE-2016-1238
-gnu/packages/php.scm:65:2: address@hidden: probably vulnerable to 
CVE-2017-5340, CVE-2016-10158, CVE-2016-10159, CVE-2016-10160, CVE-2016-10161, 
CVE-2016-10162, CVE-2016-7479
+gnu/packages/php.scm:65:2: address@hidden: probably vulnerable to 
CVE-2017-5340, CVE-2016-10158, CVE-2016-10159, CVE-2016-10160, CVE-2016-10161, 
CVE-2016-10162, CVE-2016-7479, CVE-2014-5459
+gnu/packages/polkit.scm:42:2: address@hidden: probably vulnerable to 
CVE-2016-2568
+gnu/packages/pulseaudio.scm:43:2: address@hidden: probably vulnerable to 
CVE-2014-9496, CVE-2014-9756
+gnu/packages/qemu.scm:70:2: address@hidden: probably vulnerable to 
CVE-2016-10028, CVE-2016-10029, CVE-2016-1922, CVE-2016-1981, CVE-2016-2197, 
CVE-2016-2198, CVE-2016-7161, CVE-2016-7907, CVE-2016-7908, CVE-2016-7909, 
CVE-2016-9381, CVE-2016-9776, CVE-2016-9845, CVE-2016-9846, CVE-2016-9913, 
CVE-2016-9914, CVE-2016-9915, CVE-2016-9916, CVE-2015-8701, CVE-2015-8743, 
CVE-2015-8744, CVE-2015-8745, CVE-2015-8818
+gnu/packages/ssh.scm:113:2: address@hidden: probably vulnerable to 
CVE-2014-1692
+gnu/packages/tls.scm:218:2: address@hidden: probably vulnerable to 
CVE-2014-3467, CVE-2014-3468, CVE-2014-3469
 gnu/packages/web.scm:3627:2: address@hidden: probably vulnerable to 
CVE-2016-4074
 gnu/packages/wget.scm:34:2: address@hidden: probably vulnerable to 
CVE-2017-6508
-gnu/packages/xml.scm:106:2: address@hidden: probably vulnerable to 
CVE-2016-9318
-gnu/packages/zip.scm:75:2: address@hidden: probably vulnerable to 
CVE-2016-9844, CVE-2014-9913
+gnu/packages/xml.scm:170:2: address@hidden: probably vulnerable to 
CVE-2016-4607, CVE-2016-4608, CVE-2016-4609, CVE-2016-4610, CVE-2016-4612
+gnu/packages/xml.scm:106:2: address@hidden: probably vulnerable to 
CVE-2016-2073, CVE-2016-4448, CVE-2016-9318, CVE-2015-8710
 gnu/packages/zip.scm:127:2: address@hidden: probably vulnerable to 
CVE-2017-5974, CVE-2017-5975, CVE-2017-5976, CVE-2017-5977, CVE-2017-5978, 
CVE-2017-5979, CVE-2017-5980, CVE-2017-5981
+gnu/packages/zip.scm:75:2: address@hidden: probably vulnerable to 
CVE-2016-9844, CVE-2014-9913

So that ~30 or so additional CVEs that we’d need to look at.

>> In the patch, I added the ability to specify a ‘patched-vulnerabilities’
>> property to work around that (with Coreutils as an example).  The
>> downside is that we’d have to maintain these lists by ourselves, which
>> is not great, but might still be better than the status quo.
>
> Overall, I think it's better for the CVE checker to omit some CVEs than
> to show a large number of false positives. Otherwise people may not pay
> attention to it at all. And the CVE checker will never be authoritative;
> Guix developers have to look for security advisories from a wide variety
> of sources.
>
> I wonder if we could maintain the set 'patched-vulnerabilities' fields
> satisfactorily.
>
> Changing the subject, this implementation of 'patched-vulnerabilities'
> doesn't preserve the valuable information of how we know the
> vulnerability was fixed (patch?  update? only applicable to non-GNU
> platforms? et cetera).
>
> If we were to start collecting and curating this information, we should
> try to preserve it and make it useful to the other distros.

Right, we’d need to add a clear comment to each vulnerability that we
mark as patched.

> In that case, we could instead update the CVE database through MITRE's
> new CVE form, which recently became the only way to get new CVEs from
> MITRE:
>
> https://cveform.mitre.org
>
> I think the goal is to reduce the friction of requesting and amending
> CVEs. Let's try it :)

Yes, that’s what I thought.  But either way, that’s quite a bit of
non-trivial work.

What about raising the issue on oss-sec?  Ideally the QEMU folks would
take care of labeling QEMU’s CVEs, the libxml2 folks would take care of
theirs, etc.

Thanks for your feedback!

Ludo’.