Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatch between using manifest file or not #60

Open
D4V3M0NK opened this issue Dec 9, 2020 · 4 comments
Open

Mismatch between using manifest file or not #60

D4V3M0NK opened this issue Dec 9, 2020 · 4 comments

Comments

@D4V3M0NK
Copy link

D4V3M0NK commented Dec 9, 2020

I'm completely new to cvescan (v2.5.0) but in the hour that I've been investigating, there appears to a difference in results when using a manifest file, or not.

$ cvescan
✅ Ubuntu vulnerability datbase successfully downloaded! 
✅ Scan complete!
 
Summary
------------------------------------  --------------
Ubuntu Release                        bionic
Installed Packages                    632
CVE Priority                          high or higher
Unique Packages Fixable by Patching   0
Unique CVEs Fixable by Patching       0
Vulnerabilities Fixable by Patching   0
Fixes Available by `apt-get upgrade`  0
------------------------------------  --------------

Shows that no issues are present in my system (high or higher priorities).

$ cvescan -p all
Shows that no issues are present in my system (all priorities)

However, when I generate a manifest file, it's a different matter:

$ dpkg-query -W > ~/manifest.txt
$ cvescan -p all -m ~/manifest.txt
✅ Ubuntu vulnerability datbase successfully downloaded!
✅ Scan complete!

CVE ID PRIORITY PACKAGE FIXED VERSION REPOSITORY
CVE-2019-1547 low libssl1.0.0 1.0.2n-1ubuntu5.4 Ubuntu Archive
CVE-2019-1551 low libssl1.0.0 1.0.2n-1ubuntu5.4 Ubuntu Archive
CVE-2019-1563 low libssl1.0.0 1.0.2n-1ubuntu5.4 Ubuntu Archive
CVE-2020-1968 low libssl1.0.0 1.0.2n-1ubuntu5.4 Ubuntu Archive
CVE-2020-1971 high libssl1.0.0 1.0.2n-1ubuntu5.5 Ubuntu Archive

Summary
------------------------------------ ------
Ubuntu Release bionic
Installed Packages 633
CVE Priority All
Unique Packages Fixable by Patching 1
Unique CVEs Fixable by Patching 5
Vulnerabilities Fixable by Patching 5
Fixes Available by `apt-get upgrade` 5
------------------------------------ ------
  • I see that the Installed Packages increments by one - I'm assuming that that's a reference to the manifest file itself?
  • How come I get different results with a manifest file, as opposed to not specifying one?
  • Additionally, when I pick one of the CVEs that I'm supposedly vulnerable to, it tells me that I'm not vulnerable:
$ cvescan -c CVE-2020-1971
✅ Ubuntu vulnerability datbase successfully downloaded!
✅ Scan complete!

Not affected by CVE-2020-1971.

Lastly, when I look for libssl 1.0.0, I don't see it listed:

$ apt list --installed | grep ssl

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libssl1.1/bionic,now 1.1.1-1ubuntu2.fips.2.1~18.04.3.1 amd64 [installed,automatic]
libssl1.1-hmac/bionic,now 1.1.1-1ubuntu2.fips.2.1~18.04.3.1 amd64 [installed]
libxmlsec1-openssl/bionic,now 1.2.25-1build1 amd64 [installed,automatic]
openssl/bionic,now 1.1.1-1ubuntu2.fips.2.1~18.04.3.1 amd64 [installed,automatic]
python3-openssl/bionic,now 17.5.0-1ubuntu1 all [installed,automatic]

You'll note that I am using the FIPS 140-2 certified OpenSSL package... Does that make a difference?

@mssalvatore
Copy link
Contributor

mssalvatore commented Dec 9, 2020

The way manifest files are generated right now really doesn't provide CVEScan with enough information. If you run dpkg-query --list, you'll probably see a line that looks something like:

rc  libssl1..0.0           1.0.2n-1ubuntu5.4

Whereas if you run dpkg-query -W to generate the manifest, you'll see

 libssl1.0.0           1.0.2n-1ubuntu5.4

In the output from dpkg-query --list, the first to characters, "rc" indicate that the package has been removed, but the config files have been left in place. The manifest file doesn't contain this information, so it can't filter out these scan results. In contrast, when you run CVEScan directly on a machine, it can use the dpkg-query --list output and provide more accurate results.

See #61, #56, and #53 for more information.

@D4V3M0NK
Copy link
Author

D4V3M0NK commented Dec 9, 2020

@mssalvatore Thanks for your input Mike - I take it then we have two options to obtain an accurate representation of vulnerability:

  1. Run cvescan without the manifest switch
  2. Run cvescan -m manifest.txt, with a manifest switch but generate the manifest file using (lsb_release -c && dpkg-query -f '${db:Status-Abbrev},${binary:Package},${Version},${source:Package},${Source:Version}\n' -W) | tee manifest.txt as per #53?
    1. Loving this approach as it'll work in docker containers too, from what I read
    2. Noting that at the moment, using v2.5.0, generating the manifest file in this manner generates an error in manifest_parser.py

Am I reading this all correctly?

@techalchemy
Copy link
Collaborator

@D4V3M0NK thanks for the report and for your patience with this issue. It likely won't be until some time in the new year that we release v3.0 of CVEScan and therefore a proper fix for this issue.

In the interim, can you try the following and see if it generates manifests which exclude packages which are not installed? It may be an adequate temporary solution:

grep -v -f <(dpkg --get-selections | awk '$2 ~ /deinstall/ {print $1}') <(dpkg-query -W) > manifest.txt

This essentially captures a list of previously installed packages which are now set to deinstall and searches for lines in dpkg-query -W which do not match the given uninstalled packages. We have done very limited testing with it but small samples seemed okay so far. Let us know if you are able to test this and whether you have any success. Thanks again for reporting!

@D4V3M0NK
Copy link
Author

@techalchemy no issues at all. The way I see it, you fine chaps are doing all the hard work that we get to benefit from, so it makes a change to be able to (in some minute way) assist in whatever way we can.

At the moment I'm not finding a system that I can test the same as what I had on, but I'll spin one up in the next few days and see if I can replicate the initial issue with those dastardly rc entries : then I'll be able to test your solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants