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

Debian oval does not seems to be parsed correctly #182

Open
maxenced opened this issue Dec 23, 2021 · 1 comment
Open

Debian oval does not seems to be parsed correctly #182

maxenced opened this issue Dec 23, 2021 · 1 comment
Labels

Comments

@maxenced
Copy link

What did you do? (required. The issue will be closed when not provided.)

Trying to use server mode with a payload with (fixed) openssl versions returns list of CVE that are fixed for months

What did you expect to happen?

Oval matching should only return CVE not fixed by distribution

Steps to reproduce the behaviour

With the following payload:

{
  "family": "debian",
  "version": "9.13",
  "release": "9.13",
  "runningKernel": {
    "release": "4.9.0-17-amd64",
    "version": "17"
  },
  "packages": {
    "openssl": {
      "name": "openssl",
      "version": "1.0.1t-1+deb8u8",
      "deb_status": "ii",
      "binaryNames": [
        "libssl1.0.0:amd64",
        "libssl1.1:amd64"
      ]
    }
  }
}

The following command :

curl -X POST -H "Content-Type: application/json" --data-binary @log https://vuls.endpoint

Returns the following content (truncated):

     "CVE-2016-2842": {
        "cveID": "CVE-2016-2842",
        "confidences": [
          {
            "score": 100,
            "detectionMethod": "OvalMatch"
          }
        ],
        "affectedPackages": [
          {
            "name": "openssl",
            "fixedIn": "1.0.2g-1"
          }
        ],
        "cveContents": {
          "debian": [
            {
              "type": "debian",
              "cveID": "CVE-2016-2842",
              "title": "CVE-2016-2842 openssl",
              "summary": "The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.",
              "cvss2Score": 0,
              "cvss2Vector": "",
              "cvss2Severity": "",
              "cvss3Score": 0,
              "cvss3Vector": "",
              "cvss3Severity": "",
              "sourceLink": "https://security-tracker.debian.org/tracker/CVE-2016-2842",
              "references": [
                {
                  "link": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2842",
                  "source": "CVE",
                  "refID": "CVE-2016-2842"
                }
              ],
              "published": "0001-01-01T00:00:00Z",
              "lastModified": "0001-01-01T00:00:00Z"
            }
          ],
          "nvd": [
            {
              "type": "nvd",
              "cveID": "CVE-2016-2842",
[...]

However, as per https://security-tracker.debian.org/tracker/CVE-2016-2842 the issue has been fixed in 1.1.0l-1~deb9u4 for debian stretch.

Note: We are currently using some not-released code to include #176 . Our current versions (docker based) are:

  • vuls : v0.19.0
  • cvedict : v0.8.1
  • goval-dict : latest (updated 3 days ago, so to be exact :
    Image ID:      docker-pullable://vuls/goval-dictionary@sha256:d566ee00d3ef984ed56df025518138176e75cb128ed44536da57215ba524add1

It looks like we did not have these false reports until a few days ago (so might be related to the update to d566ee0 version).

@maxenced maxenced added the bug label Dec 23, 2021
@MaineK00n
Copy link
Collaborator

MaineK00n commented Dec 24, 2021

@maxenced

I interpreted this issue as a report that this fixedIn part is wrong.

"affectedPackages": [
  {
    "name": "openssl",
    "fixedIn": "1.0.2g-1"
  }
],

However, as per https://security-tracker.debian.org/tracker/CVE-2016-2842 the issue has been fixed in 1.1.0l-1~deb9u4 for debian stretch.

Probably, 1.1.0l-1~deb9u4 of Debian Stretch refers to the currently released version, and In fact, it is fixed in 1.0.2g-1, so the status is fixed, isn't it?

At least, the openssl version in your environment is 1.0.1t-1+deb8u8, and according to OVAL and Debian Security Tracker, the fixed version of CVE-2016-2842 is 1.0.2g-1, so the results of your vuls report (CVE-2016-2842) appears to be correct.

I just looked it up and this is how it is defined.(2021/12/24 9:31 JST)

This is how it is defined in OVAL(https://www.debian.org/security/oval/oval-definitions-stretch.xml).

<definition class="vulnerability" id="oval:org.debian:def:230480040338778212221740168788749474401" version="1">
  <metadata>
    <title>CVE-2016-2842 openssl</title>
    <affected family="unix">
      <platform>Debian GNU/Linux 9</platform>
      <product>openssl</product>
    </affected>
    <reference ref_id="CVE-2016-2842" ref_url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2842" source="CVE"/>
    <description>The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.</description>
    <debian>
      <moreinfo></moreinfo>
    </debian>
  </metadata>
  <criteria comment="Release section" operator="AND">
    <criterion comment="Debian 9 is installed" test_ref="oval:org.debian.oval:tst:1"/>
    <criteria comment="Architecture section" operator="OR">
      <criteria comment="Architecture independent section" operator="AND">
        <criterion comment="all architecture" test_ref="oval:org.debian.oval:tst:2"/>
        <criterion comment="openssl DPKG is earlier than 1.0.2g-1" test_ref="oval:org.debian.oval:tst:11366"/>
      </criteria>
    </criteria>
  </criteria>
</definition>

It is also defined in gost (Debian Security Tracker: https://security-tracker.debian.org/tracker/data/json) as such.

"CVE-2016-2842": {
    "description": "The doapr_outch function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-0799.",
    "scope": "local",
    "releases": {
      "bookworm": {
        "status": "resolved",
        "repositories": { "bookworm": "1.1.1l-1" },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "bullseye": {
        "status": "resolved",
        "repositories": {
          "bullseye": "1.1.1k-1+deb11u1",
          "bullseye-security": "1.1.1k-1+deb11u1"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "buster": {
        "status": "resolved",
        "repositories": {
          "buster": "1.1.1d-0+deb10u7",
          "buster-security": "1.1.1d-0+deb10u7"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "sid": {
        "status": "resolved",
        "repositories": { "sid": "1.1.1l-1" },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      },
      "stretch": {
        "status": "resolved",
        "repositories": {
          "stretch": "1.1.0l-1~deb9u1",
          "stretch-security": "1.1.0l-1~deb9u4"
        },
        "fixed_version": "1.0.2g-1",
        "urgency": "not yet assigned"
      }
    }
},

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

No branches or pull requests

2 participants