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
