watchlists allow cvechecker to track and report on CVEs for software that cvechecker didn’t detect on the system (or perhaps even isn’t installed on the system). You can use watchlists to stay informed of potential vulnerabilities in software used at work on servers where you are not allowed (or do not want) to run cvechecker on. To use watchlists, create a text file containing the CPE identifiers for the software that you want to watch out for, and add it to the database:

~$ cat watchlist.txt
cpe:/a:microsoft:excel:2003:::

~$ cvechecker -d -w watchlist.txt
Adding CPE entries
  - Added watch for cpe:/a:microsoft:excel:2003:::

The second major feature is support for MySQL. This is the first server-oriented RDBMS that cvechecker supports (earlier versions worked with sqlite only) although sqlite support remains available as well. I hope to extend the number of supported databases in the future (say PostgreSQL, Oracle, SQL Server, …). With support for server RDBMSes came of course the requirement that multiple cvechecker clients are able to use the same server (as the CVE and CPE data itself can be shared). With the 3.0 release, this is supported as each client now “adds” to the data both his hostname as well as an (optional) user defined value (which can be anything you like). If unset, this user value is set to the hostname, but you can use things like the systems’ serial ID or asset ID.

I’m hoping all users have fun with it – I know I have while writing it. Feedback, remarks, feature requests, bugs and other criticism is always very much appreciated.

1. support the same features as cvechecker currently does using sqlite
2. streamline the database code so that duplicate code in the sqlite implementation and mysql implementation is removed
3. support multi-node systems with a single master database

The latter is something I’ve been meaning to implement for quite some time: have a single system dedicated to download and store the latest CVE entries in the database (as well as CPE definitions) whereas several systems can use the database by storing their own system information and getting a mapping from that information against the CVE database. Even more so, it would allow you to query the database asking on which systems a particular software was detected, or which systems still have vulnerable software installed.

When the MySQL support is implemented, I’m going to work a bit on the versions.dat file, because it doesn’t really support many services currently. I’m going to use it against my “virtual network” (a combination of KVM guests running bind (master/slave), ldap (multi-master), postfix, apache, squirrelmail, courier, postgresql, mysql and more) and enhance it so that it detects all those components as well.

Oh, btw, I had a request to include support for just telling cvechecker which components/software to look for (rather than it scanning the files and deducing it from regular expressions and the like). The in-svn version supports it, so it will definitely be part of the 3.0 release.

• You can now tell cvechecker to only check newly added files, or remove a set of files from its internal database. Previously, you had to have cvechecker scan the entire system again.
• cvechecker can now also report if vulnerabilities have been found in software versions that are higher than the version you currently have installed. This can help you find seriously outdated software, but also help you identify possible vulnerabilities if the CVE itself doesn’t contain all vulnerable versions, just the “latest” vulnerable version.
• The toolset now contains a command called cverules which, on a Gentoo system, will attempt to generate version matching rules for software that is currently not detected by cvechecker yet. Very useful as I myself cannot install every possible software on my system to enhance the version matching rules. If you want to help out, run the cverules command and send me the output.
• Some needed performance enhancements have been added as well

One thing I wanted to include as well was a tool that validates cvechecker output against the distribution security information. Some distributions patch software (to fix a vulnerability) rather than ask the user to upgrade to a non-vulnerable software. The cvechecker tools often cannot differentiate between the vulnerable and non-vulnerable binaries (as they both mention the same version), but often you can check against some meta data files of the distribution if and which CVEs have been resolved in which versions of a distribution package.

The cvechecker tarball contains a script (see the scripts/ folder for cvepkgcheck_gentoo) for Gentoo that tries to get this information from the GLSAs, but it is far from ready. I should try setting up a KVM instance with an “old” Gentoo installation just to validate if the command works, but even if it does, I’m not happy with how it is written. Seems to me a lot of trouble, and if it cannot be done simply, I’m afraid I’m doing it wrong ;-)

Anyhow, I hope you enjoy version 2.0 of cvechecker.

Note that the script isn’t very fast (it’s not intended to be) nor has a very high accuracy rate. After all, it does use generic regular expressions to try. The idea is that deployments on systems that have software I don’t have on my system can help me with the development of the version detection rules by sending me the output of the helper script.

Next up: tool to auto-generate (part of) the acknowledgements file for reporting purposes – getting information from distribution-specific information. Once that is in, I’ll tag it version 2.0 of cvechecker.

Now why would these functions be interesting?

Well, first of all, by supporting delta file processing I am able to use cvechecker with Portage’ hooks. Every time a package is unmerged, cvechecker will remove the files from its database (so that it doesn’t get picked up in vulnerability reports anymore). Similarly, every time a package is emerged, the files are stored in the database. There is no need to perform a full system scan every time the system has been updated.

Second, being able to report on higher version vulnerabilities the tool can now also trap potential issues with reports that do not contain the exact version as detected by cvechecker but can be relevant. For instance, a version detection of Linux 2.6.35-hardened-r1 might otherwise not be noticed (for instance because no CVE is reported on the hardened-r1 release) yet a CVE report on 2.6.35 or even 2.6.36-rc4 might be of interest. By using the higher version reporting, you’ll be notified of this as well. Same goes for vulnerability reports on an entire branch (say Python 2.4), especially when those branches are not actively being developed anymore (so the vulnerability remains). And another benefit is that you might be informed about higher versions of particular software being available ;-)

Now, a very quick warning before everybody cheers and does the penguin dance: enabling higher version reports will give you lots of false hits:

• First of all, detecting if a version is higher than another version isn’t easy. The tool is able to put 0.9.8 - 0.9.8a - 0.9.8b in the right order, as well as 0.5.1_alpha - 0.5.1_beta - 0.5.1, but the same algorithm will make 2.6.35-hardened-r1 be less than 2.6.35, and a secure 0.9.8 version will be seen vulnerable when 1.0.0_alpha has a vulnerability.
• Second of all, official CVE entries don’t always provide a good version match themselves. For instance, CVE-2008-4609 has been configured that Linux Kernel 390 and Linux Kernel 3.25 (I know those are not correct version numbers – my point exactly) are vulnerable. So yes, 390 is (a lot) higher than 2.6.35…
• Third, many tools use parallel development branches. Take Python for instance: even when version 2.6.5 would have no vulnerabilities and 2.7 or 3.2 alpha releases do, it will still report the 2.6.5 one as having a potential vulnerability. This seems to give (for me at least) the most false positives of all.

I still don’t know how to deal with this huge amount of false positives – comments are always welcome.

I plan on maintaining the earlier versions of cvechecker for two consecutive releases – one including small functional enhancements (as long as they can be applied on the development release and the stable release easily) and one just for security and bug fixes.

But is the comparison correct? If you look at a distribution as an enterprise, then surely the distinction between upstream (project development) and “downstream” (distribution) should be compared with the relations between an enterprise and its ISVs, not its internal development / operational divisions. If we look at internal divisions, then distributions tend to provide better integration between (internal) projects and the distribution. I cannot talk for every distribution, but in those I do know, the infrastructure team (“operations”) has a firm grip on the infrastructure, yet leaves out sufficient space for development to do their releases/production activity: uploading files, changing documentation, …

This works, if the provided interface does not allow for developers to harm the principles that infrastructure has. This is what many (enterprise) organizations are still lacking, but there is no simple solution for this. Often, the operations team has principles that are difficult to match with the goals of development. Finding the correct balance between development and operations in that respect is quite a challenge – usually, free software communities can get there faster, often because their mass is sufficiently low. With a total ‘employee’ count of a few hundreds it is statistically easier to find a balance than within enterprises of a few thousand employees.

I believe that both teams should write down their principles, policies and standards, and see if they can find matches (which is good) and mutually exclusive distinctions (which is challenging) where more investigation can be done. Both teams should be allowed to question decisions made by the other (but without pretending to know better) and make suggestions. This should lead to the emergence of interfaces where a team has sufficient freedom to get to their own goals autonomously.

With such interfaces, people will start thinking that devops is growing apart (after all, they’re starting to work autonomously and independently of each other). That isn’t true. In my opinion, devops is about interacting on a high level (which is less time-delimited) so that interactions on a low level (which is very time-limited and focused on releasing, releasing, releasing) aren’t necessary. Less interaction means that the teams that are responsible for getting to a specific, short time-framed goal, can cooperate closely and have a better grip on resources and requirements.

Many thanks to Nigel Horne for his continuous testing/hammering on the tool.