1.1. Background

cvechecker started to form when I noticed that more and more applications are being created based on popular free software components, ranging from small development libraries to enterprise-grade application servers and messaging systems. By itself, I applaud all use of free software - but when you make it part of another product, you must make sure that the evolutions in that component are considered with it. And that's where some vendors or users fail - they tend to include whatever version works for their product, but don't consider potential security vulnerabilities.

More than often do I notice applications that use vulnerable or even unsupported components (in which the community puts no effort in anymore). When we, at my employer, ask the vendor how riskfull he finds a particular security vulnerability that was open in the wild for a component/version he used, we more than often hear that they will update the component. But tracking components and their vulnerabilities is not our primary focus, so I thought "why not create an application or process that does it for me"?

There the idea of cvechecker was born.

1.2. Objectives

The objectives of cvechecker are:

• Be able to, given a set of files, deduce the components (with versions) that are offering these files

  For instance, a file called libbz2.so should result in the necessary identification of bzip2, version 1.0.5

• Be able to, given a deduced component, identify potential vulnerabilities by using freely available security vulnerability information

  For instance, given bzip2 version 1.0.5, report that CVE-2010-0405 might describe a potential threat

Since the start of the cvechecker project, the following objectives have been added

• Be able to, given a particular system, report on the components (with versions) found on the system

• Be able to, given a described component (without requiring cvechecker to actually deduce it from a file), identify potential vulnerabilities by using freely avaialble security vulnerability information

  For instance, give cvechecker "bzip2 version 1.0.5" and have it report that CVE-2010-0405 might describe a potential threat

1.3. Scope

The cvechecker application's current scope is to run successfully on Linux platforms, but be sufficiently platform independent to support other Unix systems. Support for the Windows platform is not in scope (but if anyone wants to take a stab or give me some pointers on how to create such platform-independent software it would be greatly appreciated).

Automated detection of software based on a heuristic approach is not in scope (in other words, software detection should always be linked with a user-defined metric, setting or expression). This is primarily to keep the scope fixed and the tools' complexity low.

The scans that cvechecker will do will be local - remotely scanning targets is not in scope.

1.4. Constraints

As I'm running free software only on my system, I can only add the necessary support for the free software components that I am running. Although I tend to have many services running in virtual environments, feedback on detection rules (cfr. the user guide documentation) is greatly appreciated.

1.5. Assumptions

The design of the tool assumes that the version of a software component is more than often hardcoded within, allowing simple expressions to extract the version from these files. This can be easily confirmed with most command-line tools:

~$ cat --version
cat (GNU coreutils) 8.7
Packaged by Gentoo (8.7 (p1))
Copyright (C) 2010 Free Software Foundation, Inc.
...
~$ strings -n 3 /bin/cat | grep 8.7
8.7
8.7 (p1)

1.6. Risks

If more and more applications do not hardcode their version in such a way that it can be easily retrieved from the file content, the method used by cvechecker will fail to deliver results. To mitigate the risk, the tool already supports the notion of "version gathering routines" so that, if necessary, additional methods can be added.

On hardened systems, not all binaries and libraries can be read. Although this is merely a matter of adjusting the security policy, this does pose a potential security problem. To mitigate the risk, the tool now also supports partial functionality (i.e. reporting) based on given information (rather than deduced).

1.7. Deliverables

Besides the objectives given earlier, the following are additional requirements / deliverables:

• Reporting should be based on CSV information (Comma Separated Values), allowing for other applications to easily work with the provided information.

2.1. Concepts

CVE-<year>-<sequence>

cpe:/<type>:<vendor>:<product>:<version>:<update>:<edition>:<language>

2.2. Logical Approach

The design of the abovementioned specific blocks is handled in the next few sections...