bitnami / vulndb Goto Github PK

Title

Minor OSV discrepancy

What steps will reproduce the bug?

Current bitnami advisories seem to encode the ecosystem name as "bitnami" (all lowercase).

e.g.

What is the expected behavior?

The ecosystem names in the OSV schema (https://ossf.github.io/osv-schema/#affectedpackage-field) are case sensitive. The ecosystem string should be encoded with an uppercase B.

e.g.

      "package": {
        "ecosystem": "Bitnami",
        "name": "activemq",
        "purl": "pkg:bitnami/activemq"
      },

What do you see instead?

      "package": {
        "ecosystem": "bitnami",
        "name": "activemq",
        "purl": "pkg:bitnami/activemq"
      },

Additional information

No response

Title

CVE-2023-39332

What steps will reproduce the bug?

The Bitnami advisory has a wrong introduced versions here.

https://github.com/bitnami/vulndb/blob/060ea7af2a3f30583bf4bf831f3711cd33cae122/data/node/BIT-2023-39332.json#L24C1-L32C1

"events": [
  {
    "introduced": "0"
  },
  {
    "fixed": "20.8.0"
  }
]

However, according the Node team, only Node 20 users are affected:

Path traversal through path stored in Uint8Array (High) - (CVE-2023-39332)
...
Impacts:

• This vulnerability affects all users using the experimental permission model in Node.js 20.x.
  Please note that at the time this CVE is issued, the permission model is an experimental feature of Node.js.

What is the expected behavior?

Ideally, it should have a better introduced version:

"events": [
  {
    "introduced": "20.0.0"
  },
  {
    "fixed": "20.8.0"
  }
]

What do you see instead?

"events": [
  {
    "introduced": "0"
  },
  {
    "fixed": "20.8.0"
  }
]

Additional information

Same issue for CVE-2023-39331, also affected only Node 20 users.

Title

CVE-2020-12603

What steps will reproduce the bug?

The Bitnami advisory has only introduced versions here.

However, the vulnerability should be fixed by 1.14.3 and 1.13.3.
GHSA-pc38-4q6c-85p6
https://groups.google.com/g/envoy-announce/c/qrrF8klFl-I/m/nz12XtqmAAAJ?pli=1

NVD pins the exact version.
https://nvd.nist.gov/vuln/detail/CVE-2020-12603

cpe:2.3:a:envoyproxy:envoy:1.13.2:::::::*
cpe:2.3:a:envoyproxy:envoy:1.14.2:::::::*

There are two problems.

1. Fixed versions in NVD are wrong in the first place
2. Bitnami wrongly parses NVD

What is the expected behavior?

Ideally, it should have the fixed version.

        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "1.13.2"
            }
            {
              "fixed": "1.13.3"
            }
          ]
        },

At least, it should pin the affected version.

        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "1.13.2"
            }
            {
              "last_affected": "1.13.2"
            }
          ]
        },

or

versions:
  - 1.13.2

I gave an example of 1.13.x, but 1.14.x is the same.

What do you see instead?

        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "1.13.2"
            }
          ]
        },

Additional information

No response

Title

Same vulnerability IDs used for distinct entries.

What steps will reproduce the bug?

For instance, there's two versions of BIT-2023-39999:

https://github.com/bitnami/vulndb/blob/87b00414368ba008df70dae5141ed0c4ca63e6eb/data/wordpress/BIT-2023-39999.json

https://github.com/bitnami/vulndb/blob/87b00414368ba008df70dae5141ed0c4ca63e6eb/data/wordpress-multisite/BIT-2023-39999.json

What is the expected behavior?

Vulnerability IDs should be unique.

These two entries should be either consolidated into a single entry (with different affected ranges referring to the distinct packages), or have different IDs.

What do you see instead?

There are two instances of e.g. BIT-2023-39999

Additional information

No response

Title

CVE-2021-44528

What steps will reproduce the bug?

$ pipenv run python -m osv.analyze_tool --analyze_git=true --format=json /tmp/BIT-rails-2021-44528.json
INFO:root:Analyzing /tmp/BIT-rails-2021-44528.json
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/analyze_tool/__main__.py", line 19, in <module>
    main()
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/analyze_tool/__init__.py", line 88, in main
    analyze(path, args.checkout_path, args.key_path, analyze_git,
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/analyze_tool/__init__.py", line 101, in analyze
    result = impact.analyze(
             ^^^^^^^^^^^^^^^
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/impact.py", line 648, in analyze
    enumerate_versions(affected.package.name, ecosystem_helpers,
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/impact.py", line 490, in enumerate_versions
    sorted_events.sort(key=sort_key)
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/impact.py", line 482, in sort_key
    return ecosystem.sort_key(event.introduced)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/ecosystems/semver_ecosystem_helper.py", line 25, in sort_key
    return semver_index.parse(version)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/google/home/apollock/gosst/osv/osv.dev/osv/semver_index.py", line 104, in parse
    return semver.Version.parse(coerce(version))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/google/home/apollock/.local/share/virtualenvs/osv.dev-cTOZqQPe/lib/python3.11/site-packages/semver/version.py", line 646, in parse
    raise ValueError(f"{version} is not valid SemVer string")
ValueError: 6.0.4.2 is not valid SemVer string

What is the expected behavior?

The version used passes SemVer validation

What do you see instead?

The version does not pass SemVer validation

Additional information

I have not exhaustively reviewed the remaining records to see how widespread this problem is.

Either the versions should be SemVer compliant, or the ranges[].type should be ECOSYSTEM

Title

CVE-2023-30581

What steps will reproduce the bug?

The Bitnami advisory has a partial fixed versions here:

"events": [
    {
    "introduced": "16.0.0"
    },
    {
    "fixed": "20.6.1"
    }
]

However, according the Node team, CVE-2023-30581is part of Node 16.20.1:

Notable Changes
The following CVEs are fixed in this release:
CVE-2023-30581: mainModule.__proto__ Bypass Experimental Policy Mechanism (High)

And also Node 18.16.1 : https://nodejs.org/en/blog/release/v18.16.1

What is the expected behavior?

Not sure, something like that:

"events": [
    {
    "introduced": "16.0.0"
    },
    {
    "fixed": "16.20.1"
    },
    {
    "introduced": "18.0.0"
    },
    {
    "fixed": "18.16.1"
    },
    {
    "introduced": "20.0.0"
    },
    {
    "fixed": "20.6.1"
    }
]

What do you see instead?

"events": [
    {
    "introduced": "16.0.0"
    },
    {
    "fixed": "20.6.1"
    }
]

Additional information

No response

Title

SEMVER ranges could be flattened

What is the problem this feature will solve?

Currently, OSV entries with multiple SEMVER ranges are provided separately:

e.g. https://github.com/bitnami/vulndb/blob/87b00414368ba008df70dae5141ed0c4ca63e6eb/data/wordpress/BIT-2023-39999.json

        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.38"
            }
          ]
        },
        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.35"
            }
          ]
        },
        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.31"
            }
          ]
        },

Instead, it's more concise (and preferred) to flatten these into:

        {
          "type": "SEMVER",
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.38"
            },
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.35"
            },
           ...
          ]
        },

What is the feature you are proposing to solve the problem?

Flatten the version ranges.