cvechecker(1)

✨ cvechecker(1) — the cvechecker Manual ✨

okay bestie, welcome to cvechecker(1), straight out of the cvechecker Manual. this is the tool that goes "hmm, what on your system is lowkey vulnerable?" and then tells you. buckle up 🎀

---

🌸 NAME 🌸

cvechecker — Attempt to identify possible vulnerable software on the system

---

🦋 SYNOPSIS 🦋

cvechecker [-i] [-l version.dat] [-b binlist.txt] [-c] [-C] [-r] [-s]
[-S] [-d] [-D] [-H] [-w watchlist.txt] [-f filename]

---

💖 DESCRIPTION 💖

so, simply stated: cvechecker matches your installed software against an online database of potentially vulnerable software, and then reports the results back to you. that's it. that's the whole vibe. ✨

to be able to figure out which software is installed on your system, cvechecker asks you to load a list of filenames (like, say, the output of a find command) into the tool using the -b (or --binlist) argument. then it tries to match those files against an internal list of known softwares. if it finds a known software title, it will attempt to discover the version of that software title. that internal list can be updated using the -l (or --loaddata) arguments.

to identify potentially vulnerable software, cvechecker downloads the CVE entries from the Mitre site and stores them in the database. the results of the CVE data + the scanned software on the system then give us the means to generate a report, listing software/version sets that have one (or more) CVE entries assigned to them. iconic. 💅

cvechecker also supports a watchlist. this is a file that contains the CPEs for which you want to watch for CVEs. the watchlist behaves as if the selected software is indeed installed on your system (so it will show up in the reports that you pull from cvechecker). using a watchlist lets administrators add software that is not detectable by cvechecker (yet). no cap. 🫶

---

👑 USAGE 👑

🧚 INITIALIZATION 🧚

to use cvechecker, you first need to initialize the databases. if your installation uses a server RDBMS (instead of sqlite) this requires database owner privileges. please consult the user guide for more info on how to initialize the database using SQL files (instead of database owner) if that's not allowed on your system. fr fr.

cvechecker -i

next, download the CVE entries from the Internet as well as the version detection rules, and load them in the database.

pullcves pull

🌈 LOAD SOFTWARE LIST 🌈

every single time your system changes, you need to (re)load the software list in the database. otherwise, cvechecker will keep on reporting about software and versions that you might not have anymore (or not report about software that you do have). a possible method is to use find to identify all executable commands and libraries, and load those into cvechecker. also, I recommend adding /proc/version because that lets cvechecker validate Linux kernel vulnerabilities too. 👑

find / -path /mnt -prune -o -path /media -prune -o -type f -perm -o+x > scanlist.txt
echo "/proc/version" >> scanlist.txt
cvechecker -b filelist.txt

it's possible to only update a part of the file database when you add the -d (--deltaonly) option. this is useful when you integrate cvechecker with your package management system. it also supports removing a part of the entries in the database (like when you uninstall software) when you add the -D (--deletedeltaonly) option. slay.

🎀 LOAD WATCHLIST 🎀

like the software list, you can have cvechecker load a watchlist. this load can happen concurrently with the filelist and also supports the delta options. be aware though: if you do not use the delta option, loading a watchlist will reload the database (clearing your detected software). as such, it is recommended to use the watchlist at the same time as your binary file listing, like so:

cvechecker -b filelist.txt -w watchlist.txt

in the reports, watchlist-provided software will have a filename starting with "<<provided>>" and named after the CPE they represent.

💜 LOAD LATEST CVE ENTRIES 💜

pull in the latest CVE entries from the Internet (see also man pullcves)

pullcves pull

🍓 REPORT ON POTENTIAL VULNERABILITIES 🍓

to get a report on potential vulnerabilities, run cvechecker with the -r argument.

cvechecker -r

if you want cvechecker to report on vulnerabilities that have been exposed with higher versions of software that you have installed, you can add the -H (--reporthigher) option. however, be warned that this will give lots of false positives 😭. the upside is that you can find potential vulnerabilities in software whose CVE entries don't contain all affected software versions (some CVEs only — falsely — contain the highest version where the vulnerability was present).

cvechecker -r -H

if you want to use the output of the command as input for other commands (for instance, to create a nice report), you can add the -C argument which makes the output csv-like:

cvechecker -r -C

🌸 REPORT ON DETECTED SOFTWARE 🌸

to get a report on the detected software, run cvechecker with the -s (only software) or -S (software with files that lead to the software detection) argument.

cvechecker -s

if you want to use the output of the command as input for other commands (for instance, to create a nice report), you can add the -C argument which makes the output csv-like:

cvechecker -s -C

---

⭐ COMMAND REFERENCE ⭐

cvechecker supports the following arguments:

• -i, --initdbs — Initialize the databases
• -l <datafile>, --loaddata=<datafile> — Load the version detection rules
• -b <binlist>, --binlist=<binlist> — Load the list of binaries available on the system. Accepts standard input if "-" is given.
• -c <cvelist>, --cvedata=<cvelist> — Load the CSV file with CVE data. The CSV file can be generated with nvd2simple, part of the cvechecker package. Normally you don't need to call this argument as it will be done by pullcves anyway.
• -f <binfilepath>, --fileinfo=<binfilepath> — Load a single file path in cvechecker. This allows you to verify if cvechecker can identify the binary or not (as it will display the CPE data if it can)
• -r, --runcheck — Match the identified software and versions against the known CVE entries and report it on the screen
• -C, --csvoutput — Report using CSV-like output.

Only interesting when used with -r or -s

• -s, --showinstalled — Show the detected software/version sets of this system
• -S, --showinstalledfiles — Show the detected software/version sets of this system together with the files that are used to detect this software/version set
• -d, --deltaonly — The file passed on through the -b (--binlist) option only contains files that need to be added to the file database (and checked for versions) rather than a full file system dump
• -D, --deletedeltaonly — The file passed on through the -b (--binlist) option only contains files that have been uninstalled from the system, and thus can be removed from the database
• -H, --reporthigher — Do not only report on CVEs that affect software installed on your system, but also on CVEs that affect higher versions of the software that is installed on your system
• -w <watchlist>, --watchlist=<watchlist> — Load the watchlist information (a file containing CPE entries — one per line — using the official CPE syntax)

🎀 CONFIGURATION FILE 🎀

okay bestie so cvechecker is thirsty for a config file, and it goes looking for it in this exact order. First it checks the CVECHECKER_CONFFILE variable. If that's not set, it goes hunting through ~/.cvechecker.rc, then /usr/local/etc/cvechecker.conf, then /etc/cvechecker.conf — whichever one shows up first wins. 💅

This file is where all the locations live, plus the other static parameters the cvechecker application needs. Here's an example config file, no cap:

#
# Generic settings
#
dbtype = "mysql";
#dbtype = "sqlite3";
cvecache = "/var/lib/cvechecker/cache";
datadir = "/usr/share/cvechecker";
stringcmd = "/usr/bin/strings -n 3 '@file@'";
version_url = "https://raw.github.com/sjvermeu/cvechecker/master/versions.dat";
#userkey = "servertag";

#
# For SQLite3
#
sqlite3: {
  localdb = "/var/lib/cvechecker/local";
  globaldb = "/var/lib/cvechecker/global.db";
}

#
# For MySQL
#
mysql: {
  dbname = "cvechecker";
  dbuser = "cvechecker_rw";
  dbpass = "passwordforcvechecker_rw";
  dbhost = "mysql.company.com";
};

And here are all the options it supports, so let's get into it ✨:

• dbtype — tells cvechecker which back-end to use. rn the supported ones are "sqlite", "sqlite3" and "mysql" (and yes, sqlite and sqlite3 land you in the same back-end, they're basically twins 👯)
• cvecache — a directory (that cvechecker can write to, ok?) where pullcves downloads all the XML files and stores the transformed XML2CSV files (the ones with the CVE entry data). So even though it's not used anymore once everything's imported into the local databases, pullcves still relies on those XML files being there to figure out if it needs to (re)download and import CVE entries. So if you wanna clean out that directory, bestie, make (empty) files named after the XML files so pullcves doesn't re-download and reimport the CVE entry data. Not like it'll render the app unusable or anything, it's just gonna take a while 😭
• datadir — a directory where cvechecker-related files live, including the XSLT transformation files used to convert CVE XML files into CSV files, plus the sample reporting files used in this very document 📄
• stringcmd — the command cvechecker launches against a file to get that file's content. rn this is the only supported method for cvechecker to identify the software/version. periodt.
• version_url — the location where pullcves can find the latest software/version matching rules so it can identify what's installed on the system 🔍
• servertag — an optional setting used when you've got server RDBMS back-ends, to differentiate between cvechecker clients. It's optional because cvechecker already uses the client's hostname as a key, but you can define a second one if you want. Maybe you're running multiple clients from the same system/hostname, or maybe you just want a more proper key for identification (like a server serial id or asset tag, cute). This key shows up in the reports 📊
• sqlite3: — combines all the sqlite-specific settings, which are:
  • localdb — a directory (cvechecker-writeable, again) where cvechecker stores its sqlite3 databases holding the CPE data (that's the identification info of software/versions), plus the local system's matching file/software pairs, plus all the downloaded CVE entries
  • globaldb — a (cvechecker-writeable) sqlite3 database containing the software/version matching rules and the CPEs associated with those rules
• mysql: — combines all the mysql-specific settings, which are:
  • dbname — the name of the cvechecker database
  • dbuser — the user that cvechecker uses to connect to the database
  • dbpass — the password cvechecker uses to connect to the database and authenticate itself
  • dbhost — the hostname where the database resides

---

💀 CVECHECKER IS NOT COMPLETE 💀

ngl this is the part where I have to be real with you. The strength of cvechecker can only fully be used if the list of supported software is huge. rn the list is too small to cover most systems. But!! if you wanna help us out in creating a larger database, please read on 🫶

The format used to import software detection rules is as follows:

,[filepart],1,[fileregexp],[contentregexp],a,[vendor],[product],[version],[update],[edition],[language]

The first comma tells cvechecker what the field separator is — so if you need to use a comma inside a regular expression, you can just use a different field separator. All you gotta do is start the line with that separator. iconic. ✨

• filepart — a string cvechecker matches against the filename (not fully qualified, keep up). If it matches, cvechecker continues investigating this file. This is merely for performance reasons, bestie, it's just there so we don't waste time.
• 1 — the type of check cvechecker executes to find out about the software's version. rn only 1 is supported. In the future more methods will be added 👀
  • The "1" method uses the output of strings <file>. That output then gets matched against a regular expression (with grouping), and the results of those matches are used to identify the version, edition, ... of the software
• fileregexp — a regular expression statement cvechecker runs against the filename (not fully qualified). If it matches, cvechecker continues investigating this file.
• contextregexp — a regular expression statement cvechecker runs against the output of the strings <file> command. If it matches, that same regular expression's grouping output gets used to fill up the metadata about the software
• a — means this is an application match. Other values are h (hardware) or o (operating system). From this point onwards, all the next fields are part of the CPE specification 💅
• vendor — the vendor name of the software. You can deduce the vendor name by surfing to the software's homepage or the vendor's homepage. The vendor name is the domain name, without any prefix or suffix. For instance, www.redhat.com yields "redhat". If no vendor exists, then the vendor is the name of the author. For instance, Sven Vermeulen yields "sven_vermeulen".
• product — the name of the software title itself
• version — the version of the software. It'll most likely use grouping references (\1, \2, ...) from the regular expression
• update — the update of the software. It'll either be empty, or use the grouping references (\1, \2, ...) from the regular expression
• edition — the edition of the software. It'll either be empty, or use the grouping references (\1, \2, ...) from the regular expression
• language — the language of the software. It'll either be empty, or use the grouping references (\1, \2, ...) from the regular expression

okay so I mentioned CPE earlier and you're probably like "bestie what". CPE stands for Common Platform Enumeration and it's a standard for identifying a product with a version. More info on CPE can be found at http://nvd.nist.gov/cpe.cfm and http://cpe.mitre.org/specification/index.html 🌈

A few examples of these detection rules, for your viewing pleasure:

,ncftp,1,ncftp,^.*NcFTP ([0-9\.]+)/([0-9]+) .*,a,ncftp_software,ncftp,\1,\2,,
,libflashplayer.so,1,libflashplayer.so,FlashPlayer_([0-9]+)_([0-9]+)_([0-9]+)_([0-9]+)_FlashPlayer,a,adobe,flash_player,\1.\2.\3.\4,,,
,perl,1,perl.*,/usr/lib/perl5/site_perl/([^/]+)/,a,perl,perl,\1,,,

---

👑 AUTHOR 👑

cvechecker was written by Sven Vermeulen <sven.vermeulen@siphos.be> 💖

---

and that's a wrap on the cvechecker(1) man page bestie 🎀 this is the cvechecker(1) page, dated August 17, 2013 / 17 August 2013, and honestly it ate. go check your CVEs, you main character 🦋💅✨