[arch-security] CVEs in Arch Linux (current, future tracking)
Hi, 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. 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. Below is an initial list of CVEs I cannot determine are actually patched (by manually looking) - so some of them are potentially false positives. Also note that CVE name mapping (CPE fields) support isn't in cve-check-tool yet, this is something I'd also like to see Arch Linux implement to ensure a maximum surface area during checks. Note the following appeared for glibc, I haven't had time to check them: CVE-2014-7817 CVE-2014-8121 [1] https://github.com/ikeydoherty/cve-check-tool - ikey packages/ namespace: exiv2: CVE-2014-9449 libzip: CVE-2015-2331 htdig: CVE-2005-0085 gksu: CVE-2014-2886 cpio: CVE-2015-1197 libtar: CVE-2013-4420 mod_fcgid: CVE-2013-4365 net-snmp: CVE-2014-2285 arora: CVE-2011-3367 rsync: CVE-2014-9512 libarchive: CVE-2013-0211 CVE-2015-2304 vorbis-tools: CVE-2014-9638 CVE-2014-9640 id3lib: CVE-2007-4460 compface: CVE-2009-2286 procmail: CVE-2014-3618 xchat: CVE-2011-5129 vte: CVE-2012-2738 fcgi: CVE-2012-6687 fastjar: CVE-2010-0831 CVE-2010-2322 ppp: CVE-2014-3158 libyaml: CVE-2014-9130 potrace: CVE-2013-7437 unzip: CVE-2014-9636 lynx: CVE-2010-2810 community/ namespace: hsolink: CVE-2010-1671 CVE-201-2929 CVE-2010-2930 arpwatch: CVE-2012-2653 echoping: CVE-2010-5111 vsftpd: CVE-2015-1419 imlib: CVE-2007-3568 uudeview: CVE-2008-2266 clearsilver: CVE-2011-4357 dtach: CVE-2012-3368 devil: CVE-2009-3994 libnids: CVE-2010-0751 tuxguitar: CVE-2010-3385 pstotext: CVE-2006-5869 plib: CVE-2011-4620 CVE-2012-4552 dopewars: CVE-2009-3591 xloadimage: CVE-2001-0775 CVE-2005-3178 xv: CVE-2004-1726 CVE-2004-1726 CVE-2005-0665 trickle: CVE-2009-0415 P.S. Apologies if message comes through twice, issues.
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 :) 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.
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.
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 [0] https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=a39208bd7
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
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
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
On 04/16/2015 01:41 AM, Ikey Doherty wrote:
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
(Please always bottom-post) I was just answering to all the information that you have posted in reply, nothing more nothing less! Also I already answered in a very positive way to your initial questions: its a great tool and I want to integrate it as additional source into the standard procedure for the security mitigation work we do in Arch Linux, look at my very first answer! Additionally I already provided some details on how you could improve the pkgbuild CVE id matching in the short term, but I will repeat it: - check CVE-ID is part of the *.patch filename at any position, allowing arbitrary prefix and suffix - also take into account that one patch filename may contain multiple CVE IDs. As I have already pointed out, I will also throw the patch-naming situation into a discussion round (but can't yet promise anything). I think I got all your initial points already and also offered and provided assistance to those. ;-) cheers Levente
On 16/04/15 01:02, Levente Polyak wrote:
On 04/16/2015 01:41 AM, Ikey Doherty wrote:
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
(Please always bottom-post)
I was just answering to all the information that you have posted in reply, nothing more nothing less!
Not suggesting otherwise. ^^
Also I already answered in a very positive way to your initial questions: its a great tool and I want to integrate it as additional source into the standard procedure for the security mitigation work we do in Arch Linux, look at my very first answer!
Yup I just didn't want to send it offtopic myself. Again, not suggesting otherwise ^^ Mostly clarifying the what is/what isn't wrt. the tool.
Additionally I already provided some details on how you could improve the pkgbuild CVE id matching in the short term, but I will repeat it: - check CVE-ID is part of the *.patch filename at any position, allowing arbitrary prefix and suffix - also take into account that one patch filename may contain multiple CVE IDs.
So with this method I can catch a *few* of them, i.e. by doing globs, but looking through there are some that won't be caught here. But its a start :) It will slow down runs of the tool but there's little can be done at this point to avoid that.
As I have already pointed out, I will also throw the patch-naming situation into a discussion round (but can't yet promise anything). I think I got all your initial points already and also offered and provided assistance to those. ;-)
Tbh patch naming for CVEs only became more of an issue to me when writing the tool, up until that point I personally had no reason for even doing it in my own projects :) (normally git format-patch, etc.) - ikey
cheers Levente
participants (3)
-
Allan McRae
-
Ikey Doherty
-
Levente Polyak