GHSA-HXF5-99XG-86HW

Vulnerability from github – Published: 2024-11-05 22:19 – Updated: 2024-11-06 14:28
VLAI?
Summary
cap-std doesn't fully sandbox all the Windows device filenames
Details

Impact

cap-std's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.

Patches

The bug is fixed in https://github.com/bytecodealliance/cap-std/pull/371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.

Workarounds

There are no known workarounds for this issue. Affected Windows users are recommended to upgrade.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "cap-std"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "cap-async-std"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "cap-primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-51756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-05T22:19:59Z",
    "nvd_published_at": "2024-11-05T22:15:21Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\ncap-std\u0027s filesystem sandbox implementation on Windows blocks access to special device filenames such as \"COM1\", \"COM2\", \"LPT0\", \"LPT1\", and so on, however it did not block access to the special device filenames which use superscript digits, such as \"COM\u00b9\", \"COM\u00b2\", \"LPT\u2070\", \"LPT\u00b9\", and so on. Untrusted filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.\n\n### Patches\n\nThe bug is fixed in https://github.com/bytecodealliance/cap-std/pull/371, which is published in cap-primitives 3.4.1, cap-std 3.4.1, and cap-async-std 3.4.1.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Affected Windows users are recommended to upgrade.\n\n### References\n\n - [Microsoft\u0027s documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) of the special device filenames\n - [ISO-8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)\n - https://github.com/bytecodealliance/cap-std/pull/371\n",
  "id": "GHSA-hxf5-99xg-86hw",
  "modified": "2024-11-06T14:28:24Z",
  "published": "2024-11-05T22:19:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/cap-std/security/advisories/GHSA-hxf5-99xg-86hw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51756"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/cap-std/pull/371"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/cap-std/commit/dcc3818039761331fbeacbb3a40c542b65b5ebf7"
    },
    {
      "type": "WEB",
      "url": "https://en.wikipedia.org/wiki/ISO/IEC_8859-1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/cap-std"
    },
    {
      "type": "WEB",
      "url": "https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "cap-std doesn\u0027t fully sandbox all the Windows device filenames"
}


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…