Add remediation category "fix_planned"

[mreedergithub]

Add the “fixed_planned” option to the Category of the Remediation list of values. The use case is when there is a fix for the Known_Affected versions that is being worked on and will be available at a specified date. Having the “fix_planned” category for remediation will provide clarity that to the customer that a fix is being worked instead of non_available.

[santosomar]

As discussed in the Nov 29, 2023 meeting, this issue could be coupled and related to #563

[mreedergithub]

@tschmidtb51 - per your request, below is an example of our DSA where the fix for the vulnerability is planned for a future date. Please let me know if this is what you are looking for.

DSA-2023-047 (https://www.dell.com/support/kbdoc/en-us/000210952/dsa-2023-047)

CSAF json sample using the remediation category “fix_planned”:

"vulnerabilities": [
    {
      "cve": "CVE-2022-0778",
      "notes": [
        {
          "category": "description",
          "text": "The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).",
          "title": "CVE Description"
        }
      ],
      "cwe": {
        "id": "CWE-863",
        "name": "Incorrect Authorization"
      },
      "product_status": {
        "known_affected": [
          "CSAFPID-0005"
        ]
      },
      "remediations": [
        {
          "category": "fix_planned",
          "details": "Upgrade to version >=1.9.0 when the fix is released",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-03-09T17:00:00.000Z"
        }
      ],

[tschmidtb51]

This is related to #665

[tschmidtb51]

@tschmidtb51 - per your request, below is an example of our DSA where the fix for the vulnerability is planned for a future date. Please let me know if this is what you are looking for.

@mreedergithub Thank you for the example. I had a look into the example you linked and it says that the product is EoL. Do you still plan the fix or is 1.9.0 already released?

[tschmidtb51]

For documentation purposes and comparison: Here is the example from above as it would be stated in CSAF 2.0, assuming that 1.9.0 is not yet released but the release is planned on 2023-03-09.

Before 2023-03-09 (e.g. 2023-02-01):

"vulnerabilities": [
    {
      "cve": "CVE-2022-0778",
      "notes": [
        {
          "category": "description",
          "text": "The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).",
          "title": "CVE Description"
        }
      ],
      "cwe": {
        "id": "CWE-863",
        "name": "Incorrect Authorization"
      },
      "product_status": {
        "known_affected": [
          "CSAFPID-0005"
        ]
      },
      "remediations": [
        {
          "category": "none_available",
          "details": "The fix is currently being developed. Upgrade to version >=1.9.0 when the fix is released",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-02-01T17:00:00.000Z"
        },
        {
          "category": "vendor_fix",
          "details": "Upgrade to version >=1.9.0",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-03-09T17:00:00.000Z"
        }
      ]
     // ...
   }
   //...
]

And for completeness: after 2023-03-09 - when the fix has been released:

"vulnerabilities": [
    {
      "cve": "CVE-2022-0778",
      "notes": [
        {
          "category": "description",
          "text": "The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).",
          "title": "CVE Description"
        }
      ],
      "cwe": {
        "id": "CWE-863",
        "name": "Incorrect Authorization"
      },
      "product_status": {
        "known_affected": [
          "CSAFPID-0005"
        ]
      },
      "remediations": [
        {
          "category": "vendor_fix",
          "details": "Upgrade to version >=1.9.0",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-03-09T17:00:00.000Z"
        }
      ]
     // ...
   }
   //...
]

[mreedergithub]

@tschmidtb51 - Please see my response to your question below.
"Thank you for the example. I had a look into the example you linked and it says that the product is EoL.
Do you still plan the fix or is 1.9.0 already released?

{MR} - This DSA example is not a good example as the fix has already been released on 2023-03-09. We have use case scenarios where the fix is planned for future dates and having the remediation category - "fix_planned" will help provide more clarity to the customer that a fix is being worked on, instead of "none_available" which can cause confusions for the customer to think that there is no fix.

Similar to the example you shared above, but we would like the remediation category = "fix_planned"

"remediations": [
{
"category": "fix_planned",
"details": "The fix is currently being developed. Upgrade to version >=1.9.0 when the fix is released",
"product_ids": [
"CSAFPID-0005"
],
"date": "2023-03-09T17:00:00.000Z"

[tschmidtb51]

@mreedergithub I understand the example. I was just confused about the EoL part...

Anyways, I think the example is okay to get the TC an impression what the request is about. My comment should just clarify the current situation, so that everyone can compare and see the changes.

[jdstefaniak]

Hello, please consider this real life business case in this Security Advisory: DSA-2024-021

From time-to-times, there will be the need to publish a Security Advisory, which will not contain an actual remediation at the time of publication.

Having a remediation_category "fix_planned"; would enable us to deliver meaningful communication for the Consumers to plan for their business operations accordingly; is a must.
Cc: @mreedergithub @tschmidtb51

[jdstefaniak]

1- Practical: Vendors will have the need at times to communicate about a known vulnerability in their product(s) ahead of delivering the remediation. This is done to be transparent with Customers and an acknowledged necessity to increase the bond of trust between Customers and their vendors. Therefore, for a Vendor to be able to publish a CSAF payload with a "Fix_Planned" field and value simply serves this purpose. Dell Security Advisories rely on this strategy every time for one product at least, example to be discussed if necessary (see revision table): dsa-2023-156-dell-bsafe-ssl-j-7-1-1-security-update

2- Industry Guidelines: FIRST.org lists at least one scenario with examples where this option of communicating a vulnerability ahead of delivering the remediation is needed: Use Case 3: Public disclosure of limited vulnerability information prior to remediation ; see practical examples with offering an advanced warning or expected cadence.
That second point further aligns the CSAF standard with the FIRST guidelines for Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure

Thanks again for your time and attention.
Cc: @santosomar , @tschmidtb51 , @mreedergithub

[jdstefaniak]

@santosomar , @tschmidtb51 I would like to respectfully request we continue exploring this ask during the next meeting of the TC please.
Please let @mreedergithub and I know if you would consider and any questions you may have in the meantime.
Thank You,
Regards,
JD

[tschmidtb51]

@mreedergithub, @jdstefaniak: I looked into this, how it should be implemented (and also the conversion rule). My understanding is that you would have one item with fix_planned and the current date as date and one with vendor_fix and the anticipated release date of the fix as date. Please see the example below:

"vulnerabilities": [
    {
      "cve": "CVE-2022-0778",
      "notes": [
        {
          "category": "description",
          "text": "The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).",
          "title": "CVE Description"
        }
      ],
      "cwe": {
        "id": "CWE-863",
        "name": "Incorrect Authorization"
      },
      "product_status": {
        "known_affected": [
          "CSAFPID-0005"
        ]
      },
      "remediations": [
        {
          "category": "fix_planned",
          "details": "The fix is currently being developed. Upgrade to version >=1.9.0 when the fix is released",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-02-01T17:00:00.000Z"
        },
        {
          "category": "vendor_fix",
          "details": "Upgrade to version >=1.9.0",
          "product_ids": [
            "CSAFPID-0005"
          ],
          "date": "2023-03-09T17:00:00.000Z"
        }
      ]
     // ...
   }
   //...
]

[jdstefaniak]

Thank you @tschmidtb51 for your review and suggestions.

From our perspective:
"fix_planned": should display the date the Vendor has planned to deliver the remediation for all products in scope
"vendor_fix": as per the existing definition; should contain the date when the remediation has been fully delivered by the Vendor.

This is particularly aligned in that scenario with a Vendor delivering a remediation in a staggered fashion as per the FIRST's PSIRT Service Framework:

Function 4.2.3 Remedy Delivery:
[./.] others may align the disclosure to come after the remedies have been released particularly if the remedies have been staged or in some cases the disclosures may be prioritized [./.]

I hope this provides a useful and actionable context to this thread. Please let me know of any follow up questions Thomas.
Cc: @mreedergithub

[tschmidtb51]

There was a motion for this issue: https://groups.oasis-open.org/discussion/motion-for-662-1

[tschmidtb51]

@mreedergithub, @ jdstefaniak: Please have a look at the suggestion in #804