FreeBSD Manual Pages
cvechecker(1) cvechecker Manual cvechecker(1) 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 cvechecker is a tool that, simply stated, matches your installed soft- ware versus an online database of potential vulnerable software and re- port the results back to you. To be able to identify which software is installed on your system, cvechecker asks you to load a list of filenames (such as the output of a find command) into the tool using the -b (or --binlist) argument. It will then try to match the files against an internal list of known softwares. If it finds a known software title, it will attempt to dis- cover the version of this software title. This internal list can be up- dated using the -l (or --loaddata) arguments. To identify potential vulnerable software, cvechecker downloads the CVE entries from the Mitre site and stores it in the database. The results of the CVE data and the scanned software on the system then provides us with the means to generate a report, listing software/version sets that have one (or more) CVE entries assigned to them. 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 be visible in the reports that you pull from cvechecker). Using a watch- list allows administrators to add software that is not detectable by cvechecker (yet). USAGE INITIALIZATION To use cvechecker, you first need to initialize the the databases. If your installation uses a server RDBMS (instead of sqlite) this requires database owner privileges. Please consult the user guide for more in- formation on how to initialize the database using SQL files (instead of database owner) if this is not allowed on your system. 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 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 have). A possible method is to use find to identify all executable commands and libraries and load those in cvechecker. I also recommend to add /proc/version as this allows cvechecker to validate Linux kernel vulnerabilities as well. 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 is 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 remov- ing a part of the entries in the database (such as when you uninstall software) when you add the -D (--deletedeltaonly) option. 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 that, if you do not use the delta op- tion, loading a watchlist will reload the database (clearing your de- tected software). As such, it is recommended to use the watchlist at the same time with your binary file listing, like so:pr cvechecker -b filelist.txt -w watchlist.txt In the reports, watchlist-provided software will have a filename start- ing 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 pull- cves) 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 ex- posed 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 doesn't contain all af- fected software versions (some CVEs only - falsely - contain the high- est version where the vulnerability was present). cvechecker -r -H If you want to use the output of the command as input for other com- mands (for instance, to create a nice report), you can add the -C argu- ment 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 com- mands (for instance, to create a nice report), you can add the -C argu- ment 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 stan- dard 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 con- tains 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 con- tains 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 cvechecker will read the configuration file pointed towards by the CVECHECKER_CONFFILE variable. If that variable is not set, ~/.cvecheck- er.rc, /usr/local/etc/cvechecker.conf or /etc/cvechecker.conf, whichev- er comes first. This file contains the locations as well as other stat- ic parameters for the cvechecker application. An example configuration file is: # # 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"; }; The following options are supported: • dbtype tells the cvechecker application which back-end to use. Cur- rently, "sqlite", "sqlite3" and "mysql" are supported (sqlite and sqlite3 result in the same back-end) • cvecache is a (cvechecker writeable) directory where pullcves will download all XML files and store the transformed XML2CSV files (con- taining the CVE entry data). Although it is not used anymore after being imported into the local databases, pullcves relies on the availability of the XML files to find out if it needs to (re)download and import CVE entries. So if you want to clean out the directory, make (empty) files named after the XML files so that pullcves does not redownload and reimport the CVE entry data (not that this will render the application unusable, but it takes a while) • datadir is a directory where cvechecker-related files are stored, in- cluding the XSLT transformation files used to convert CVE XML files in CSV files as well as the sample reporting files as used in this document • stringcmd is the command that cvechecker launches against a file to get the files' content. Currently, this is the only supported method for cvechecker to identify the software/version. • version_url is the location where pullcves can find the latest soft- ware/version matching rules to identify installed software on the system. • servertag is an optional setting that is used in case of server RDBMS backends to differentiate between the cvechecker clients. It is op- tional, because cvechecker already uses the clients' hostname as a key, but users can define a second one. This can be both because they want to run multiple clients from the same system/hostname, or be- cause they want a more proper key for their identification (such as a server serial id or asset tag). This key is displayed in the reports. • sqlite3: combines all sqlite specific settings, which are: • localdb is a (cvechecker writeable) directory where cvechecker will store its sqlite3 databases containing the CPE data (identification information of software/versions) as well as the local systems' matching file/software pairs and all downloaded CVE entries • globaldb is a (cvechecker writeable) sqlite3 database containing the software/version matching rules and CPEs associated with these rules • mysql: combines all mysql specific settings, which are: • dbname is the name of the cvechecker database • dbuser is the user that cvechecker uses to connect to the database • dbpass is the password that cvechecker uses to connect to the data- base and authenticate itself • dbhost is the hostname where the database resides CVECHECKER IS NOT COMPLETE The strength of cvechecker can only be fully used if the list of sup- ported software is huge. Currently, the list is too small to cover most systems. However, if you want to help us out in creating a larger data- base, 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 the comma in a regular expression, you can use a different field separator. Just start the line with the separator. • filepart is a string which cvechecker will match against the filename (not fully qualified). If it matches, cvechecker will continue with this file's investigation. This is merely for performance reasons • 1 is the type of check that cvechecker will execute to find out about the software's version. Currently, only 1 is supported. In the fu- ture, more methods will be added. • The "1" method uses the output of strings <file>. The output is then matched against a regular expression (with grouping) and the results of the matches are then used to identify the version, edi- tion, ... of the software • fileregexp is a regular expression statement that cvechecker will run against the filename (not fully qualified). If it matches, cvechecker will continue with this file's investigation. • contextregexp is a regular expression statement that cvechecker will run against the output of the strings <file> command. If it matches, the same regular expressions' grouping output will be used to fill up the metadata about the software • a means that this is an application match. Other values are h (hard- ware) or o (operating system). From this point onwards, all next fields are part of the CPE specification • vendor is the vendor name of the software. You can deduce the vendor name by surfing to the software's homepage/vendor's homepage. The vendor name is the domainname, without any prefix or suffix. For in- stance, 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 is the name of the software title itself • version is the version of the software. It will most likely use grouping references (\1, \2, ...) from the regular expression • update is the update of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression • edition is the edition of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression • language is the language of the software. It will either be empty, or use the grouping references (\1, \2, ...) from the regular expression I have mentioned CPE. CPE stands for Common Platform Enumeration and is a standard for identifying a product with version. More information 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: ,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>. August 17, 2013 17 August 2013 cvechecker(1)
NAME | SYNOPSIS | DESCRIPTION | USAGE | COMMAND REFERENCE | CONFIGURATION FILE | CVECHECKER IS NOT COMPLETE | AUTHOR
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=cvechecker&sektion=1&manpath=FreeBSD+Ports+15.0>