Example for installed packages would be helpful

[viraptor]

From what I get from the docs and some source browsing, I could provide a list of packages manually via the faux plugin and then scan that list like this:

cve-check-tool -t faux -N some.csv

But it doesn't seem to work the way I expect it to. Let's say I expect to find https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7187 and provide the following csv:

bash,1.0,,

I get the file listed as scanned (Scanned 1 source file), but no results about issues found.

Maybe I'm missing something trivial. My goal was to run dpkg -l -O | awk '/^ii/ { print $2 "," $3 ",," }' > installed_list.csv and feed that file to cve-check-tool later.

[ikeydoherty]

Hi

This isn't how cve-check-tool currently works. It doesn't yet know about installed packages, rather, it deals with source packages and analyses those. However I'm happy to remedy that.

[ikeydoherty]

OK so looking at the new tool, this is some of the output we get about CVE-2014-7187

 ikey@solus-bdw  ~/Projects/cve-check-tool   2  time ./src/cli/cve-check-tool info CVE-2014-7187
WARNING: Loading NVD SQL from: /home/ikey/Projects/cve-check-tool/src/datasource/nvd/database.sql
WARNING: Loading NVD INI from: /home/ikey/Projects/cve-check-tool/src/datasource/nvd/sqlite3.ini
Information for CVE-2014-7187
Summary: Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue.
Vulnerable Product: gnu:bash version 1.14.0
Vulnerable Product: gnu:bash version 1.14.1
Vulnerable Product: gnu:bash version 1.14.2
Vulnerable Product: gnu:bash version 1.14.3
Vulnerable Product: gnu:bash version 1.14.4
Vulnerable Product: gnu:bash version 1.14.5
Vulnerable Product: gnu:bash version 1.14.6
Vulnerable Product: gnu:bash version 1.14.7
Vulnerable Product: gnu:bash version 2.0
Vulnerable Product: gnu:bash version 2.01
Vulnerable Product: gnu:bash version 2.01.1
Vulnerable Product: gnu:bash version 2.02
Vulnerable Product: gnu:bash version 2.02.1
Vulnerable Product: gnu:bash version 2.03
Vulnerable Product: gnu:bash version 2.04
Vulnerable Product: gnu:bash version 2.05
Vulnerable Product: gnu:bash version 2.05:a
Vulnerable Product: gnu:bash version 2.05:b
Vulnerable Product: gnu:bash version 3.0
Vulnerable Product: gnu:bash version 3.0.16
Vulnerable Product: gnu:bash version 3.1
Vulnerable Product: gnu:bash version 3.2
Vulnerable Product: gnu:bash version 3.2.48
Vulnerable Product: gnu:bash version 4.0
Vulnerable Product: gnu:bash version 4.0:rc1
Vulnerable Product: gnu:bash version 4.1
Vulnerable Product: gnu:bash version 4.2
Vulnerable Product: gnu:bash version 4.3

Please note the glaring absence of 1.0 as per the CVE data.

Examining further for 1.0:

sqlite> select * from versions v inner join products p on v.product_id = p.hash where product = 'bash' and version = '1.0';

No results...

To list all known versions of bash as dictated by the National Vulnerability Database:

sqlite> select distinct version from versions v inner join products p on v.product_id = p.hash where product = 'bash' order by version asc;
1.14.0
1.14.1
1.14.2
1.14.3
1.14.4
1.14.5
1.14.6
1.14.7
2.0
2.01
2.01.1
2.02
2.02.1
2.03
2.04
2.05
2.05:a
2.05:b
3.0
3.0.16
3.1
3.2
3.2.48
4.0
4.0:rc1
4.1
4.2
4.3
sqlite> 

We can see 1.0 is never listed. Which poses an issue.

[ikeydoherty]

Also note that for this reason the new tool which is being developed in branch 2 demoted the National Vulnerability Database's status to a data source, with the view to employing more sources. (There are other reasons too.)