search

oasis-tcs / csaf

OASIS CSAF TC: Supporting version control for Work Product artifacts developed by members of TC, including prose specifications and secondary artifacts like meeting minutes and productivity code
https://github.com/oasis-tcs/csaf
Other
147 stars 39 forks source link

Support for Multiple Products and Platforms for a CSAF advisory for a given Vulnerability. #773

Closed santosomar closed 2 months ago

santosomar commented 2 months ago

Scenario 1: A CSAF VEX advisory can provide the status of one vulnerability in one product, as shown below: image

Scenario 2: A CSAF VEX advisory can also provide the status of multiple vulnerabilities that may affect/not affect a product: image

Scenario 3: Alternately, a CSAF VEX advisory could provide the status of multiple products that may be affected by a given vulnerability. In other words, you can go to a vendor/provider/maintainer and ask: “tell me the status of CVE-2029–0123 in all your products (i.e., the products under investigation, affected, not affected, or fixed).

image

However, the current CSAF 2.0 schema does not allow a vendor/provider/maintainer to provide notes about different products to one CVE, as shown in Scenario 3. For example, a product may have different versions or platforms of that product that may be affected by that vulnerability but other versions or platforms for that exact product may not be affected by that vulnerability. There are no capabilities to include those notes in the advisory when you have the scenario of one CVE --> to many products/platforms/versions in CSAF 2.0

tschmidtb51 commented 2 months ago

@santosomar: Maybe, I misunderstood you but I think this is already possible with CSAF 2.0:

Please see my example below:

As the example is quite long, I made it expandable - so click me ```json { "document": { "category": "csaf_vex", "csaf_version": "2.0", "notes": [ { "category": "summary", "text": "Example Company VEX document. Unofficial content for demonstration purposes only.", "title": "Author comment" } ], "publisher": { "category": "vendor", "name": "Example Company ProductCERT", "namespace": "https://example.com/psirt" }, "title": "Example VEX", "tracking": { "current_release_date": "2022-03-03T11:00:00.000Z", "generator": { "date": "2022-03-03T11:00:00.000Z", "engine": { "name": "Secvisogram", "version": "1.11.0" } }, "id": "EVD-2022-06-001", "initial_release_date": "2022-03-03T11:00:00.000Z", "revision_history": [ { "date": "2022-03-03T11:00:00.000Z", "number": "1", "summary": "Initial version." } ], "status": "final", "version": "1" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version", "name": "4.2", "product": { "name": "Example Company ABC 4.2", "product_id": "CSAFPID-0001" } }, { "category": "product_version", "name": "2.4", "product": { "product_id": "CSAFPID-0002", "name": "Example Company ABC 2.4" } }, { "category": "product_version", "name": "2.6", "product": { "product_id": "CSAFPID-0003", "name": "Example Company ABC 2.6" } }, { "category": "product_version_range", "name": "vers:generic/>=2.9|<4.1", "product": { "product_id": "CSAFPID-0004", "name": "Example Company ABC >=2.9|<4.1" } }, { "category": "product_version_range", "name": "vers:generic/>=1.0|<=2.3", "product": { "product_id": "CSAFPID-0005", "name": "Example Company ABC >=1.0|<=2.3" } }, { "category": "product_version", "name": "2.5", "product": { "product_id": "CSAFPID-0006", "name": "Example Company ABC 2.5" } }, { "category": "product_version_range", "name": "vers:generic/>=2.7|<=2.8", "product": { "product_id": "CSAFPID-0007", "name": "Example Company ABC >=2.7|<=2.8" } }, { "category": "product_version", "name": "4.1", "product": { "name": "Example Company ABC 4.1", "product_id": "CSAFPID-0008" } } ], "category": "product_name", "name": "ABC" } ], "category": "vendor", "name": "Example Company" } ] }, "vulnerabilities": [ { "cve": "CVE-2021-44228", "notes": [ { "category": "description", "text": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.", "title": "CVE description" } ], "product_status": { "known_affected": [ "CSAFPID-0002", "CSAFPID-0003", "CSAFPID-0004" ], "known_not_affected": [ "CSAFPID-0005", "CSAFPID-0006", "CSAFPID-0007" ], "fixed": [ "CSAFPID-0001" ], "under_investigation": [ "CSAFPID-0008" ] }, "references": [ { "category": "external", "summary": "NVD - CVE-2021-44228", "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228" } ], "remediations": [ { "category": "vendor_fix", "details": "Update to version 4.2 or later.", "product_ids": [ "CSAFPID-0002", "CSAFPID-0003", "CSAFPID-0004" ] } ], "scores": [ { "cvss_v3": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 10, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "version": "3.1" }, "products": [ "CSAFPID-0002", "CSAFPID-0003", "CSAFPID-0004" ] }, { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/MC:N/MI:N/MA:N", "baseScore": 10, "baseSeverity": "CRITICAL", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "CHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "modifiedConfidentialityImpact": "NONE", "modifiedIntegrityImpact": "NONE", "modifiedAvailabilityImpact": "NONE" }, "products": [ "CSAFPID-0001", "CSAFPID-0005", "CSAFPID-0006", "CSAFPID-0007" ] } ], "threats": [ { "category": "impact", "details": "Class with vulnerable code was removed before shipping.", "product_ids": [ "CSAFPID-0001", "CSAFPID-0005", "CSAFPID-0006", "CSAFPID-0007" ] } ] } ] } ```

If I misunderstood you, please clarify. Also see https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/examples/csaf/csaf_vex/2022-evd-uc-07-001.json as example.

PS: Please don't use future CVEs in examples as this might cause confusion in the future. According to the CNA rules section 5.4, there is a specific range defined for examples.

mprpic commented 2 months ago

Scenario 3 is also how Red Hat structures our VEX files, see e.g.:

https://access.redhat.com/security/data/csaf/v2/vex/2024/cve-2024-6716.json

Multiple products are described in the product tree and the product status of that single vulnerability is defined for each.

DarioCiccarone commented 2 months ago

@tschmidtb51 For each product referenced in the VEX document, we would like to provide two additional pieces of data: a) additional clarifying details on how we determined the status of a given product regarding the vulnerability and b) the internal bug identifier used to track the fix for that vulnerability for that product

After reviewing the example JSON document you referenced, we realize we can use the Vulnerability Property and reference the correct product_ids to fulfill the requirement (a). However, we're currently unsure how to satisfy the requirement (b). Specifically, we need to figure out how to link the bug ID to the product. Here's an example (using as a reference the same example JSON document you referenced before, 2022-evd-uc-07-001.json):

Based on the current CSAF specification, we can use the relevant product_ids with the following:

The problem is that 3.2.3.6 (Vulnerabilities Property - IDs), as we understand the CSAF 2.0 specification, only allows for two properties: "system_name" and "text" - but it does NOT allow the inclusion of any product_ids.

So, there is no issue if the VEX document refers to a [single product, single CVE ID] or [single product, multiple CVE IDs]. The problem arises when your VEX document represents [multiple products, single CVE ID] or [multiple products, multiple CVE IDs].

This is an example of a VEX document "single product, single CVE ID" - no issues here:

"vulnerabilities": [ { "cve": "CVE-2021-44228", "notes": [ { "category": "description", "text": "blah blah", "title": "CVE description" } ], "ids": [ { "system_name": "Cisco Bug ID", "text": "CSCaa11111" } ], "product_status": { "known_affected": [ "CSAFPID-0002" ] },

But in the example [multiple products, single CVE ID], we would have:

"vulnerabilities": [ { "cve": "CVE-2021-44228", "notes": [ { "category": "description", "text": "blah blah", "title": "CVE description" } ], "ids": [ { "system_name": "Cisco Bug ID", "text": "CSCaa11111" }, { "system_name": "Cisco Bug ID", "text": "CSCxy99999" } ], "product_status": { "known_affected": [ "CSAFPID-0002", "CSAFPID-0003" ] },

That is the problem - there's no way to map each entry in "ids" to a specific product_id. What we would need to have (and it seems we don't) is this:

"vulnerabilities": [ { "cve": "CVE-2021-44228", "notes": [ { "category": "description", "text": "blah blah", "title": "CVE description" } ], "ids": [ { "system_name": "Cisco Bug ID", "text": "CSCaa11111", "applies_to": [ "CSAFPID-0002" ] }, { "system_name": "Cisco Bug ID", "text": "CSCxy99999", "applies_to" : [ "CSAFPID-0003" ] } ], "product_status": { "known_affected": [ "CSAFPID-0002", "CSAFPID-0003" ] },

That "applies_to" property binds the "id" to a given product_id (or a set of product_id entries if the same bug tracking id applies to more than a single product).

tschmidtb51 commented 2 months ago

@DarioCiccarone Thank you for clarifying your request.

This need to be discussed in the TC. The main questions for the TC are:

  1. Do we want to allow to bind ids on product_ids?
  2. Do we want to allow to bind ids on group_ids?
  3. Should the binding be mandatory?
  4. Is there a use case, where the ids point to an outside / upstream system that of which not products are present in the VEX? If so, this answers 3. (IMHO, there is - exactly in VEX.)
tschmidtb51 commented 2 months ago

Some minor comments:

  • flags to communicate VEX justifications (for products with a status of affected)

I guess, its a typo. Correct would be: flags to communicate VEX justifications (for products with a status of not affected)

threats to communicate additional information on how we determined the status.

I would rather put that into notes. I think there was the idea to add product_ids as an optional field to notes, but I haven't found the issue right now.

DarioCiccarone commented 2 months ago

Some minor comments:

  • flags to communicate VEX justifications (for products with a status of affected)

I guess, its a typo. Correct would be: flags to communicate VEX justifications (for products with a status of not affected)

You are correct, of course. I meant to say "for NOT affected." Thanks for catching that.

threats to communicate additional information on how we determined the status.

I would rather put that into notes. I think there was the idea to add product_ids as an optional field to notes, but I haven't found the issue right now.

Yeah, that's the problem of using the notes - if I am listing three products as "Not Affected" and five others as "Affected," I might have two notes (note 1 applies to the Not Affected ones and note 2 to the Affected ones), or in the worst case scenario, I might have fives. And as you point out above, there's currently also no way to bind a givennote instance to a single product_id or a set of product_ids

But threats with a category value of impact would work perfectly for our purposes, I think - from the example JSON file we've been using all this time:

  "threats": [
    {
      "category": "impact",
      "details": "Class with vulnerable code was removed before shipping.",
      "product_ids": [
        "CSAFPID-0001",
        "CSAFPID-0005",
        "CSAFPID-0006",
        "CSAFPID-0007"
      ]
    },
    {
      "category": "impact",
      "details": "Log4j was not included in those versions at all.",
      "product_ids": [
        "CSAFPID-0009"
      ]
    }
  ]

That additional information provided in details is precisely what we want to deliver.

However, after re-checking the documentation for threats at https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#32314-vulnerabilities-property---threats, it becomes clear that the spirit, or purpose, of the threat, impact property was very different from how it is being used in the example . . . Using it for our stated purpose would match the way it is used within the example, but doesn't match the stated purpose of the property on the CSAF 2.0 documentation.

tschmidtb51 commented 2 months ago

threats to communicate additional information on how we determined the status.

I would rather put that into notes. I think there was the idea to add product_ids as an optional field to notes, but I haven't found the issue right now.

Sorry - I think I misunderstood you. You are right that the impact statement (as shown in the example) belongs into the threats object.

That additional information provided in details is precisely what we want to deliver.

However, after re-checking the documentation for threats at https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#32314-vulnerabilities-property---threats, it becomes clear that the spirit, or purpose, of the threat, impact property was very different from how it is being used in the example . .

The threats' details fields with impact as category is exactly where an impact statement should be in CSAF: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex Also the documentation IMHO clearly states that the information why something is not exploitable belongs there:

The value impact indicates that the details field contains an assessment of the impact on the user or the target set if the vulnerability is successfully exploited or a description why it cannot be exploited.

Sorry, again about the confusion.

santosomar commented 2 months ago

As discussed in our TC meeting on 2024-08-28, there were two issues presented here. The first item is already addressed in the current standard version (CSAF 2.0). The threats with a category value of impact addresses the concern.

The second issue is that in the current version of CSAF (2.0), there's a challenge with using the notes field effectively. For instance, if you need to list three products as "Not Affected" and five others as "Affected," you might create two notes (one for the "Not Affected" products and another for the "Affected" ones). However, in a worst-case scenario, you might end up needing five separate notes. Moreover, there's currently no mechanism to bind a specific note instance to an individual product_id or a set of product_ids, which further complicates the clarity and precision of the documentation.

During the TC, it was suggested to close this issue and open a new one to address the second item described here.

santosomar commented 2 months ago

Refer to https://github.com/oasis-tcs/csaf/issues/780