Trivy: Gemfile.lock not installed gems

Created on 15 Nov 2019 · 14Comments · Source: aquasecurity/trivy

Trivy is reading the Gemfile.lock and not the installed gems. This is causing false positives.

Target": "rails/vendor/bundle/ruby/2.6.0/gems/awesome_print-1.8.0/Gemfile.lock",
    "Vulnerabilities": [
      {
        "VulnerabilityID": "CVE-2019-11068",
        "PkgName": "nokogiri",
        "InstalledVersion": "1.8.0",
        "FixedVersion": "\u003e= 1.10.3",

The only installed gems for nokogiri, is nokogiri-1.10.5 . Even though the awesome_print-1.8.0/Gemfile.lock has nokogiri (1.8.0), that does not mean that is the running version of nokogiri. I have checked and nokogiri (1.8.0) was never installed.

What did you expect to happen?

The Trivy expected behavior would be to scan awesome_print-1.8.0/Gemfile.lock find all vulnerabilities and compare them against the installed gems.

What happened instead?

Trivy reported vulnerability for a gem version that was never installed.

Output of run with -debug:

trivy -s HIGH,CRITICAL -f json --ignore-unfixed -debug hub.docker.com/my-image:1.0
2019-11-15T09:50:05.326-0500    [35mDEBUG[0m  cache dir:  /Users/xxxx/Library/Caches/trivy
2019-11-15T09:50:05.332-0500    [35mDEBUG[0m  DB update was skipped because DB is the latest
2019-11-15T09:50:05.332-0500    [35mDEBUG[0m  Vulnerability type:  [os library]
2019-11-15T09:50:09.361-0500    [35mDEBUG[0m  OS family: alpine, OS version: 3.10.2
2019-11-15T09:50:09.362-0500    [35mDEBUG[0m  the number of packages: 69
2019-11-15T09:50:09.865-0500    [35mDEBUG[0m  the number of packages from commands: 112
2019-11-15T09:50:09.865-0500    [35mDEBUG[0m  the number of packages: 123
2019-11-15T09:50:09.865-0500    [34mINFO[0m   Detecting Alpine vulnerabilities...
2019-11-15T09:50:09.865-0500    [35mDEBUG[0m  alpine: os version: 3.10
2019-11-15T09:50:09.865-0500    [35mDEBUG[0m  alpine: the number of packages: 123
2019-11-15T09:50:09.877-0500    [34mINFO[0m   Detecting bundler vulnerabilities...
2019-11-15T09:50:09.877-0500    [35mDEBUG[0m  Detecting library vulnerabilities, path: rails/vendor/bundle/ruby/2.6.0/gems/awesome_print-1.8.0/Gemfile.lock
2019-11-15T09:50:09.881-0500    [34mINFO[0m   Detecting bundler vulnerabilities...
2019-11-15T09:50:09.897-0500    [33mWARN[0m   failed to get the vulnerability: failed to marshal JSON: unexpected end of JSON input
[
  ...
  {
    "Target": "rails/vendor/bundle/ruby/2.6.0/gems/awesome_print-1.8.0/Gemfile.lock",
    "Vulnerabilities": [
      {
        "VulnerabilityID": "CVE-2019-11068",
        "PkgName": "nokogiri",
        "InstalledVersion": "1.8.0",
        "FixedVersion": "\u003e= 1.10.3",
...

Output of trivy -v:

trivy -v
trivy version 0.2.0

Additional details (base image name, container registry info...):

kinbug

Source

strangeminds

Most helpful comment

@knqyf263 Thank you, this can help, but on the other hand there may be gems that are installed and will not be verified, the problem is the same gems that are present both in the main Gemfile.lock and in the other Gemfiles.locks except that the last updated version is always installed and Trivy is taking older versions that are not installed. Thanks for your reply

yrosaguiar on 15 Jul 2020

👍5

All 14 comments

@strangeminds Thanks. This problem will be resolved in the next version.
https://github.com/aquasecurity/trivy/pull/279

knqyf263 on 15 Nov 2019

Would you try v0.2.1? If there is still a problem, please reopen this.

knqyf263 on 15 Nov 2019

Would you try v0.2.1? If there is still a problem, please reopen this.

v0.2.1 fixed the issue. Thanks!

strangeminds on 18 Nov 2019

👍1

Hello,

This issue appears to be present in 0.5.3, unless I'm misinterpreting something.

var/lib/gems/2.5.0/gems/jslint_on_rails-1.1.1/Gemfile.lock
==========================================================
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 2)

+---------+------------------+----------+-------------------+---------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+---------+------------------+----------+-------------------+---------------+
| rake    | CVE-2020-8130    | CRITICAL | 0.9.2             | >= 12.3.3     |
+         +                  +          +                   +               +
|         |                  |          |                   |               |
+---------+------------------+----------+-------------------+---------------+

However that version of rake is not installed in the container:

root@217c9ea6300c:/usr/src/app# bundle show rake
/var/lib/gems/2.5.0/gems/rake-13.0.1

root@217c9ea6300c:/usr/src/app# gem list | grep rake
rake (13.0.1)

gwirth@Garets-MacBook-Pro ~ % trivy -v
Version: 0.5.3
Vulnerability DB:
  Type:
  Version: 1
  UpdatedAt: 2020-03-30 12:08:43.123780205 +0000 UTC
  NextUpdate: 2020-03-31 00:08:43.123779805 +0000 UTC

Any advice here would be great!

gvwirth on 30 Mar 2020

Problem still exist in latest version (0.9.1)

It couldn't detect installed gem version correctly and give lots of false positive alarms. It is not possible to use trivy in most of the ruby projects.

demirten on 24 Jun 2020

We are facing the same problem, Trivy analyzes the gemfile.lock instead of analyzing the gems that are installed, the problem is that it is also looking at the gemfiles.locks downloaded from the main project's dependencies and actually the version of the gem that is installed is the main project and not the old versions that are listed in the gemfiles.locks of the premises I believe that a good approach would be to run the command gem list to get the gems that are actually installed and direct the output to a file, Trivy would the test on top of that file. e.g. gem list> file.txt && trivy file.txt

yrosaguiar on 9 Jul 2020

👍4

Hi @yrosaguiar, thank you for your explanation. Parsing Gemfile.lock has advantages as well as downsides as you described. We have a plan to parse all gem packages instead of Gemfile.lock, but it isn't coming soon. At the moment, we can add an option to skip traversing directories. Does it make sense to your case?

knqyf263 on 14 Jul 2020

yrosaguiar on 15 Jul 2020

👍5

Thank you for your reply. Let me clarify my understanding as follows:

/main/Gemfile.lock --> install redis 4.0
/main/vendor/bundle/other/Gemfile.lock --> install redis 3.0

In this case, if you run bundle install in /main/, only redis-4.0 is installed according to your comment, right?

the version of the gem that is installed is the main project and not the old versions that are listed in the gemfiles.locks of the premises

In the example above, if redis-3.0 from /main/vendor/other/Gemfile.lock is not installed, why does Trivy take older versions that are not installed? If you ignore main/vendor directory, redis-3.0 is not detected by Trivy. If redis-3.0 is installed, we need to look at /main/vendor/bundle/other/Gemfile.lock as well.

the problem is the same gems that are present both in the main Gemfile.lock and in the other Gemfiles.locks except that the last updated version is always installed and Trivy is taking older versions that are not installed

It would be helpful if you give me a more detailed example.

knqyf263 on 16 Jul 2020

@knqyf263 Yes. I will try to explain using examples:

Trivy output:

usr/local/bundle/gems/rack-proxy-0.6.5/Gemfile.lock
 ===================================================
 Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)
 +---------+------------------+----------+-------------------+---------------+--------------------------------+
 | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
 +---------+------------------+----------+-------------------+---------------+--------------------------------+
 | rake    | CVE-2020-8130    | CRITICAL | 0.9.2.2           | 12.3.3        | rake: OS Command Injection via |
 |         |                  |          |                   |               | egrep in Rake::FileList        |
 +---------+------------------+----------+-------------------+---------------+--------------------------------+
 usr/local/bundle/gems/webpacker-3.2.0/Gemfile.lock
 ==================================================
 Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)
 +---------+------------------+----------+-------------------+---------------+--------------------------------+
 | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
 +---------+------------------+----------+-------------------+---------------+--------------------------------+
 | rake    | CVE-2020-8130    | CRITICAL | 12.3.0            | 12.3.3        | rake: OS Command Injection via |
 |         |                  |          |                   |               | egrep in Rake::FileList        |
 +---------+------------------+----------+-------------------+---------------+--------------------------------+

Output from gem list (installed version) on container:

/app # gem list|grep rake
rake (13.0.1)
/app # gem list|grep webpacker
webpacker (3.2.0)

Gem versions from main project:

/app # cat Gemfile.lock |grep rake
rake (>= 0.8.7)
rake (13.0.1)
/app # cat Gemfile.lock |grep webpacker
webpacker (3.2.0)
webpacker (= 3.2.0)

Gem version from dependencies:

/app # cat /usr/local/bundle/gems/rack-proxy-0.6.5/Gemfile.lock|grep rake
rake (0.9.2.2)
rake

/app # cat /usr/local/bundle/gems/webpacker-3.2.0/Gemfile.lock|grep rake
rake (>= 0.8.7)
rake
rake (12.3.0)
rake (>= 11.1)

I'm not sure of trivy's behavior, as I don't understand how it treats gems, what I'm sur;e of is that it doesn't analyze the version that is installed. I think that you temporary solution (an option to skip traversing directories) can solve this problem. Thank you

yrosaguiar on 16 Jul 2020

@yrosaguiar Thank you for the example!

In your example, usr/local/bundle/gems/rack-proxy-0.6.5/Gemfile.lock and usr/local/bundle/gems/webpacker-3.2.0/Gemfile.lock just exist as the dependency in the image and the gems in those lock files are not installed actually. It looks like the image runs bundle install with /app/Gemfile.lock and installs only rake-13.0.1. So, the installed gems in the image and the gems listed in /app/Gemfile.lock should be almost the same except for gems you install by gem install command.

In short, the option should work as a workaround if you skip traversing /usr/local/bundle/gems. On the other hand, your image runs bundle install with /usr/local/bundle/gems/rack-proxy-0.6.5/Gemfile.lock, this lock file should not be ignored. Please correct me if I'm wrong.

We'll be working on the new option. Let me know if the option doesn't make sense and doesn't work with your issue.

knqyf263 on 16 Jul 2020

@knqyf263 I believe it will help, after this explanation that you showed, I believe it makes sense. I don't know if it would be in that same issue, but from what I saw, the same behavior happens with yarn.lock for nodejs applications ,detail this yarn.lock is from a dependency gem of the ruby application, is not from a nodejs application. It is the same application ruby explained before

usr/local/bundle/gems/webpacker-3.2.0/yarn.lock
 ===============================================
 Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 3)
 +------------+------------------+----------+-------------------+---------------+--------------------------------+
 |  LIBRARY   | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
 +------------+------------------+----------+-------------------+---------------+--------------------------------+
 | cryptiles  | CVE-2018-1000620 | CRITICAL | 2.0.5             | 4.1.2         | nodejs-cryptiles: Insecure     |
 |            |                  |          |                   |               | randomness causes the          |
 |            |                  |          |                   |               | randomDigits() function        |
 |            |                  |          |                   |               | returns a pseudo-random data   |
 |            |                  |          |                   |               | string...                      |

Thanks for the answer =)

yrosaguiar on 16 Jul 2020

👍1

@knqyf263 Hey, I'm having the same problem here. Do you have an ETA or some place that we can follow this new feature?

xxxmadxxx on 30 Jul 2020

Could an alternative solution here be to perform gem cleanup all after running bundle install? This should remove old or stale gems from you system, therefore, trivy should only scan the latest version of any installed gems.