Schema issue with CAN-2022-1000071

[ninoseki]

Hello, I maybe wrong where to report this issue but let me try.

CAN-2022-1000071 in https://osv-vulnerabilities.storage.googleapis.com/GSD/all.zip violates the OSV schema.

{
  "id": "CAN-2022-1000071",
  "summary": "Default Credentials in XB6 Fibre+ Gateway version XB6_0821",
  "details": "In Shaw Communications Inc XB6 Fibre+ Gateway version XB6_0821 a Default Credentials exists in the Router/Modem that can be attacked via local access resulting in Admin access to router",
  "modified": "2022-02-01T19:38:14.238938Z",
  "published": "2022-02-01T19:38:14.238938Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://support.shaw.ca/t5/internet-articles/guide-fibre-gateway-xb6-xb7/ta-p/5114"
    },
    {
      "type": "WEB"
    }
  ],
  "affected": [
    {
      "package": {
        "name": "XB6 Fibre+ Gateway",
        "ecosystem": "GSD"
      },
      "versions": [
        "XB6_0821"
      ],
      "database_specific": {
        "source": "https://github.com/cloudsecurityalliance/gsd-database/blob/main/2022/1000xxx/GSD-2022-1000071.json"
      }
    }
  ],
  "schema_version": "1.3.0"
}

reference (in references) should have url but not.
I cannot find the original data source. So maybe there is something wrong the original data side not osv.dev side.

[ninoseki]

GSD-2022-1006324 has the same issue.

{
  "id": "GSD-2022-1006324",
  "summary": "unknown in Exchange Server version Exchange Server 2019",
  "details": "In Microsoft Exchange Server version Exchange Server 2019 and possibly earlier an undisclosed vulnerability exists in an undisclosed component that can be attacked via the network, reportedly resulting in remote code execution. This is also known as ZDI-CAN-18333, and public reports of exploitation are available. There are additional reports that indicate that attackers may be making use of an older, known (and fixed) vulnerability and that these newly exploited systems are not correctly patched and vulnerable to older exploits, however it should be noted that the ZDI reference does exist.",
  "modified": "2022-09-29T23:23:36.412033Z",
  "published": "2022-09-29T23:23:36.412033Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html"
    },
    {
      "type": "WEB"
    }
  ],
  "affected": [
    {
      "package": {
        "name": "Exchange Server",
        "ecosystem": "GSD"
      },
      "versions": [
        "Exchange Server 2019"
      ],
      "database_specific": {
        "source": "https://github.com/cloudsecurityalliance/gsd-database/blob/main/2022/1006xxx/GSD-2022-1006324.json"
      }
    }
  ],
  "schema_version": "1.3.0"
}

[andrewpollock]

Preliminary investigation...

https://osv.dev/vulnerability/CAN-2022-1000071 points to https://github.com/cloudsecurityalliance/gsd-database/blob/main/2022/1000xxx/GSD-2022-1000071.json as the source

• The OSV record at the source appears well formed

https://osv.dev/vulnerability/GSD-2022-1006324 points to https://github.com/cloudsecurityalliance/gsd-database/blob/main/2022/1006xxx/GSD-2022-1006324.json as the source

• this seems to have been subsequently withdrawn

[andrewpollock]

Taking a further look, I can see this commit, which appears to fix the problem.

My current theory is that OSV ingested invalid input (which I think we can agree is a bug), and then failed to reflect the correction afterwards (which I'd also consider a bug).

[oliverchang]

hmm, CloudSecurityAlliance/gsd-database@8d56a3f didn't update the modified timestamp, which may have lead to us not picking it up.

[andrewpollock]

The preceding commit, CloudSecurityAlliance/gsd-database@fc3bfdd also did not update the modified timestamp it appears. This commit renamed the OSV identifier from CAN-2022-1000071 to GSD-2022-1006324

[andrewpollock]

Apologies, I misspoke in #761 (comment). Let me try again.

The preceding commit, CloudSecurityAlliance/gsd-database@fc3bfdd also did not update the modified timestamp it appears. This commit renamed the OSV identifier from CAN-2022-1000071 to GSD-2022-1000071

[andrewpollock]

And looking at the story for GSD-2022-1006324, I can see that CloudSecurityAlliance/gsd-database@12cef35 committed the file with an invalid reference and then the followup commit (CloudSecurityAlliance/gsd-database@19eb962) that withdrew it did update the modification timestamp and also removed the references entirely.

https://github.com/cloudsecurityalliance/gsd-database/commits/main/2022/1006xxx/GSD-2022-1006324.json

@kurtseifried since you were involved with both commits, I'll signal-boost this as problem with how OSV records are being generated.

[kurtseifried]

Sorry I'm not clear, GSD-2022-1006324.json is valid OSV, even after withdrawal:
gsd-tools/local-scripts/schema-validator/validate-json-file.py ./GSD-2022-1006324.json ########################################################################### FILENAME: GSD-2022-1006324.json ######################################## gsd DATA PARSED CLEAN
DATA PARSED CLEAN

[kurtseifried]

As for the rest we're not generating valid OSV, yet. We're working towards that. I'm rejiggering my converter scripts, having written up some ugly stuff that sort of works, now I think I know what we actually need. GSD is very much a work in progress.

Also long term for data ingestion we'll have the API.

[andrewpollock]

Hey @kurtseifried

GSD-2022-1006324.json is valid now, it wasn't valid as of CloudSecurityAlliance/gsd-database@12cef35
CAN-2022-1000071 aka GSD-2022-1000071 wasn't initially committed validly at CloudSecurityAlliance/gsd-database@22635a9 either

Given that I've seen two instances of this, I wanted to flag it.

[kurtseifried]

Correct. As I said we're still working on our file format. Hopefully, in a few weeks, we'll have a solution and converted data.

[andrewpollock]

We've looked into this in more detail, and:

for CAN-2022-1000071 aka GSD-2022-1000071, OSV does not appear to be handling file renames, so we'll file a separate issue to add that functionality. Because the data was corrected post-rename, the renamed entry for GSD-2022-1000071. CAN-2022-1000071 should be treated the same as a delete and marked as invalid.

for GSD-2022-1006324, it has been withdrawn, but that withdrawn record doesn't seem to be considered valid by our importer, so is being disregarded.

@kurtseifried looking more closely at CloudSecurityAlliance/gsd-database@12cef35 again, this commit only has GSD data in it, not OSV, so that's why OSV will be rejecting it. I note your validator has only picked up on the GSD syntax in the file.

[andrewpollock]

I misspoke again with respect to renames. No file was renamed, the identifier was.

[kurtseifried]

Sorry when you say "so that's why OSV will be rejecting it" do you mean the schema or? Like I said, working on the converter so that the gsd:osv_schema will be an OSV schema passing chunk of JSON.

[andrewpollock]

@kurtseifried when we were investigating this issue earlier today, we could see import attempts for GSD-2022-1006324 (https://github.com/cloudsecurityalliance/gsd-database/blob/0d4aee1251653a43fc1fb1e9b46a1fb2abfac04e/2022/1006xxx/GSD-2022-1006324.json) being rejected repeatedly, because there's no OSV entry in that particular file.

[andrewpollock]

Based on the specific examples of data invalidity highlighted in reported issue, we've identified a few pieces of work that need to happen to prevent the underlying issues from recurring.

There remains the issue of correcting these specific instances in OSV.

[andrewpollock]

There remains the issue of correcting these specific instances in OSV.

My current thinking is to:

• directly delete CAN-2022-1000071 from Data Store, since it is also present as GSD-2022-1000071
• directly delete GSD-2022-1006324 from Data Store, since it's been retracted per https://github.com/cloudsecurityalliance/gsd-database/blob/0d4aee1251653a43fc1fb1e9b46a1fb2abfac04e/2022/1006xxx/GSD-2022-1006324.json

Consulting with the rest of the team on this approach.

[andrewpollock]

@oliverchang what are your thoughts on:

• Marking CAN-2022-1000071 (and the other single-digit number of CAN-* records) as invalid
• Marking GSD-2022-1006324 as invalid

Then I think we can call this specific issue closed, and focus on the broader issues captured earlier on this issue.

[oliverchang]

@oliverchang what are your thoughts on:

• Marking CAN-2022-1000071 (and the other single-digit number of CAN-* records) as invalid
• Marking GSD-2022-1006324 as invalid

Then I think we can call this specific issue closed, and focus on the broader issues captured earlier on this issue.

Sounds good to me!

[andrewpollock]

@oliverchang what are your thoughts on:

• Marking CAN-2022-1000071 (and the other single-digit number of CAN-* records) as invalid
• Marking GSD-2022-1006324 as invalid

Then I think we can call this specific issue closed, and focus on the broader issues captured earlier on this issue.

Sounds good to me!

CAN-2022-1000071
CAN-2022-1000284
CAN-2022-1002518

marked as invalid

GSD-2022-1006324

marked as invalid