GHSA-CXW4-9QV9-VX5H

Vulnerability from github – Published: 2019-09-30 19:42 – Updated: 2022-01-18 23:06
VLAI?
Summary
High severity vulnerability that affects PeterO.Cbor
Details

Impact

The CBOR library supports optional tags that enable CBOR objects to contain references to objects within them. Versions earlier than 4.0 resolved those references automatically. While this by itself doesn't cause much of a security problem, a denial of service can happen if those references are deeply nested and used multiple times (so that the same reference to the same object occurs multiple times), and if the decoded CBOR object is sent to a serialization method such as EncodeToBytes, ToString, or ToJSONString, since the objects referred to are expanded in the process and take up orders of magnitude more memory than if the references weren't resolved.

The impact of this problem on any particular system varies. In general, the risk is higher if the system allows users to send arbitrary CBOR objects without authentication, or exposes a remote endpoint in which arbitrary CBOR objects can be sent without authentication.

Patches

This problem is addressed in version 4.0 by disabling reference resolution by default. Users should use the latest version of this library.

Workarounds

Since version 3.6, an encoding option (resolvereferences=true or resolvereferences=false) in CBOREncodeOptions sets whether the CBOR processor will resolve these kinds of references when decoding a CBOR object. Set resolvereferences=false to disable reference resolution.

In version 3.6, if the method used CBORObject.Read() or CBORObject.DecodeFromBytes() to decode a serialized CBOR object, call the overload that takes CBOREncodeOptions as follows:

CBORObject.DecodeFromBytes(bytes, new CBOREncodeOptions("resolvereferences=false"));

In versions 3.5 and earlier, this issue is present only if the CBOR object is an array or a map. If the application does not expect a decoded CBOR object to be an array or a map, it should check the CBOR object's type before encoding that object, as follows:

if (cbor.Type != CBORType.Array && cbor.Type != CBORType.Map) {
   cbor.EncodeToBytes();
}

Alternatively, for such versions, the application can use WriteTo to decode the CBOR object to a so-called "limited memory stream", that is, a Stream that throws an exception if too many bytes would be written. How to write such a limited-memory stream is nontrivial and beyond the scope of this advisory.

using(var stream = new LimitedMemoryStream(100000)) { // Limit to 100000 bytes
     cbor.WriteTo(stream);
     return stream.ToBytes();
}

To check whether a byte array representing a CBOR object might exhibit this problem, check whether the array contains the byte 0xd8 followed immediately by either 0x19 or 0x1d. This check catches all affected CBOR objects but may catch some non-affected CBOR objects (notably integers and byte strings).

References

See the Wikipedia article Billion laughs attack and the related issue in Kubernetes.

For more information

If you have any questions or comments about this advisory: * Open an issue in the CBOR repository.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "PeterO.Cbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:33:21Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe CBOR library supports optional tags that enable CBOR objects to contain references to objects within them. Versions earlier than 4.0 resolved those references automatically. While this by itself doesn\u0027t cause much of a security problem, a denial of service can happen if those references are deeply nested and used multiple times (so that the same reference to the same object occurs multiple times), and if the decoded CBOR object is sent to a serialization method such as `EncodeToBytes`, `ToString`, or `ToJSONString`, since the objects referred to are expanded in the process and take up orders of magnitude more memory than if the references weren\u0027t resolved.\n\nThe impact of this problem on any particular system varies.  In general, the risk is higher if the system allows users to send arbitrary CBOR objects without authentication, or exposes a remote endpoint in which arbitrary CBOR objects can be sent without authentication.\n\n### Patches\nThis problem is addressed in version 4.0 by disabling reference resolution by default.  Users should use the latest version of this library.\n\n### Workarounds\nSince version 3.6, an encoding option (`resolvereferences=true` or `resolvereferences=false`) in CBOREncodeOptions sets whether the CBOR processor will resolve these kinds of references when decoding a CBOR object.  Set `resolvereferences=false` to disable reference resolution.\n\nIn version 3.6, if the method used `CBORObject.Read()` or `CBORObject.DecodeFromBytes()` to decode a serialized CBOR object, call the overload that takes `CBOREncodeOptions` as follows:\n\n    CBORObject.DecodeFromBytes(bytes, new CBOREncodeOptions(\"resolvereferences=false\"));\n\nIn versions 3.5 and earlier, this issue is present only if the CBOR object is an array or a map.  If the application does not expect a decoded CBOR object to be an array or a map, it should check the CBOR object\u0027s type before encoding that object, as follows:\n\n    if (cbor.Type != CBORType.Array \u0026\u0026 cbor.Type != CBORType.Map) {\n       cbor.EncodeToBytes();\n    }\n\nAlternatively, for such versions, the application can use `WriteTo` to decode the CBOR object to a so-called \"limited memory stream\", that is, a `Stream` that throws an exception if too many bytes would be written.  How to write such a limited-memory stream is nontrivial and beyond the scope of this advisory.\n\n    using(var stream = new LimitedMemoryStream(100000)) { // Limit to 100000 bytes\n         cbor.WriteTo(stream);\n         return stream.ToBytes();\n    }\n\nTo check whether a byte array representing a CBOR object might exhibit this problem, check whether the array contains the byte 0xd8 followed immediately by either 0x19 or 0x1d.  This check catches all affected CBOR objects but may catch some non-affected CBOR objects (notably integers and byte strings).\n\n### References\n\nSee the Wikipedia article [Billion laughs attack](https://en.wikipedia.org/wiki/Billion_laughs_attack) and the related issue in [Kubernetes](https://github.com/kubernetes/kubernetes/issues/83253).\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the CBOR repository](https://github.com/peteroupc/CBOR).\n",
  "id": "GHSA-cxw4-9qv9-vx5h",
  "modified": "2022-01-18T23:06:09Z",
  "published": "2019-09-30T19:42:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/peteroupc/CBOR/security/advisories/GHSA-cxw4-9qv9-vx5h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/peteroupc/CBOR"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "High severity vulnerability that affects PeterO.Cbor"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…