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