From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Dealing with CVEs that apply to unspecified package versions Date: Sat, 11 Mar 2017 12:09:32 +0100 Message-ID: <87bmt89ij7.fsf@gnu.org> References: <877f4284un.fsf@gnu.org> <20170311040534.GA31017@jasmine> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmeu4-0006qz-4U for guix-devel@gnu.org; Sat, 11 Mar 2017 06:09:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cmetz-0005TP-4h for guix-devel@gnu.org; Sat, 11 Mar 2017 06:09:40 -0500 In-Reply-To: <20170311040534.GA31017@jasmine> (Leo Famulari's message of "Fri, 10 Mar 2017 23:05:34 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Leo Famulari skribis: > On Mon, Mar 06, 2017 at 10:36:48PM +0100, Ludovic Court=C3=A8s wrote: >> Unfortunately, there=E2=80=99s no way to know whether such CVEs are actu= ally >> fixed at a specific package version or not, and they=E2=80=99re not unco= mmon. >> Consequently, =E2=80=98guix lint -c cve=E2=80=99 would now report old CV= Es 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=E2=80=99s the before/after diff I get: --=-=-= Content-Type: text/x-patch Content-Disposition: inline --- /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: gnutls@3.5.8: probably vulnerable to CVE-2014-3467, CVE-2014-3468, CVE-2014-3469 gnu/packages/backup.scm:186:2: libarchive@3.2.1: probably vulnerable to CVE-2016-8687, CVE-2016-8688, CVE-2016-8689 -gnu/packages/base.scm:754:2: glibc@2.23: probably vulnerable to CVE-2016-3075, CVE-2016-5417 -gnu/packages/base.scm:502:2: glibc@2.24: probably vulnerable to CVE-2016-6323 -gnu/packages/base.scm:788:2: glibc@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547, CVE-2014-7817, CVE-2014-8121 +gnu/packages/base.scm:278:2: coreutils@8.25: probably vulnerable to CVE-2014-9471 +gnu/packages/base.scm:767:2: glibc@2.22: 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: glibc@2.21: 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: tar@1.29: probably vulnerable to CVE-2016-6321 -gnu/packages/base.scm:766:2: glibc@2.22: 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: glibc@2.24: probably vulnerable to CVE-2016-3706, CVE-2016-4429, CVE-2016-6323, CVE-2014-5119 +gnu/packages/base.scm:755:2: glibc@2.23: probably vulnerable to CVE-2016-3075, CVE-2016-3706, CVE-2016-4429, CVE-2016-5417, CVE-2014-5119 +gnu/packages/bash.scm:269:2: bash@4.4.A: probably vulnerable to CVE-2016-9401 +gnu/packages/busybox.scm:31:2: busybox@1.26.0: probably vulnerable to CVE-2016-6301 gnu/packages/compression.scm:210:4: bzip2@1.0.6: probably vulnerable to CVE-2016-3189 -gnu/packages/image.scm:296:2: libtiff@4.0.7: probably vulnerable to CVE-2017-5563, CVE-2016-10095 -gnu/packages/image.scm:487:2: openjpeg@2.1.2: 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: mariadb@10.1.21: probably vulnerable to CVE-2016-6664 +gnu/packages/databases.scm:720:2: sqlite@3.15.1: probably vulnerable to CVE-2015-3717 +gnu/packages/databases.scm:254:2: mysql@5.7.17: probably vulnerable to CVE-2014-0001 +gnu/packages/databases.scm:666:2: sqlite@3.14.1: probably vulnerable to CVE-2015-3717 +gnu/packages/gcc.scm:410:2: libiberty@4.9.4: 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: lcms@2.6: probably vulnerable to CVE-2016-10165 +gnu/packages/gnome.scm:5393:4: byzanz@0.2-1.f7af3a5: probably vulnerable to CVE-2015-2785 +gnu/packages/gstreamer.scm:99:2: gstreamer@1.10.4: probably vulnerable to CVE-2017-5847, CVE-2017-5848, CVE-2016-9446 +gnu/packages/image.scm:487:2: openjpeg@2.1.2: 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: libtiff@4.0.7: 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: openjpeg@1.5.2: probably vulnerable to CVE-2016-7163, CVE-2016-9675 +gnu/packages/linux.scm:3063:2: ecryptfs-utils@111: probably vulnerable to CVE-2016-1572 +gnu/packages/lynx.scm:35:2: lynx@2.8.9dev.11: probably vulnerable to CVE-2016-9179 gnu/packages/mail.scm:1081:2: dovecot@2.2.27: probably vulnerable to CVE-2016-8652 gnu/packages/monitoring.scm:34:2: nagios@4.2.4: probably vulnerable to CVE-2016-10089 gnu/packages/mp3.scm:231:2: libmp3splt@0.9.2: probably vulnerable to CVE-2017-5665 gnu/packages/mp3.scm:264:2: mp3splt@2.6.2: probably vulnerable to CVE-2017-5666, CVE-2017-5851 +gnu/packages/openldap.scm:36:2: openldap@2.4.44: probably vulnerable to CVE-2015-3276 gnu/packages/perl.scm:50:2: perl@5.24.0: probably vulnerable to CVE-2016-1238 -gnu/packages/php.scm:65:2: php@7.0.14: 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: php@7.0.14: 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: polkit@0.113: probably vulnerable to CVE-2016-2568 +gnu/packages/pulseaudio.scm:43:2: libsndfile@1.0.26: probably vulnerable to CVE-2014-9496, CVE-2014-9756 +gnu/packages/qemu.scm:70:2: qemu@2.8.0: 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: openssh@7.4p1: probably vulnerable to CVE-2014-1692 +gnu/packages/tls.scm:218:2: gnutls@3.5.8: probably vulnerable to CVE-2014-3467, CVE-2014-3468, CVE-2014-3469 gnu/packages/web.scm:3627:2: jq@1.5: probably vulnerable to CVE-2016-4074 gnu/packages/wget.scm:34:2: wget@1.19.1: probably vulnerable to CVE-2017-6508 -gnu/packages/xml.scm:106:2: libxml2@2.9.4: probably vulnerable to CVE-2016-9318 -gnu/packages/zip.scm:75:2: unzip@6.0: probably vulnerable to CVE-2016-9844, CVE-2014-9913 +gnu/packages/xml.scm:170:2: libxslt@1.1.29: probably vulnerable to CVE-2016-4607, CVE-2016-4608, CVE-2016-4609, CVE-2016-4610, CVE-2016-4612 +gnu/packages/xml.scm:106:2: libxml2@2.9.4: probably vulnerable to CVE-2016-2073, CVE-2016-4448, CVE-2016-9318, CVE-2015-8710 gnu/packages/zip.scm:127:2: zziplib@0.13.62: 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: unzip@6.0: probably vulnerable to CVE-2016-9844, CVE-2014-9913 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So that ~30 or so additional CVEs that we=E2=80=99d need to look at. >> In the patch, I added the ability to specify a =E2=80=98patched-vulnerab= ilities=E2=80=99 >> property to work around that (with Coreutils as an example). The >> downside is that we=E2=80=99d 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=E2=80=99d 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=E2=80=99s what I thought. But either way, that=E2=80=99s 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=E2=80=99s CVEs, the libxml2 folks would take car= e of theirs, etc. Thanks for your feedback! Ludo=E2=80=99. --=-=-=--