GHSA-XPWJ-7V8Q-MCGJ

Vulnerability from github – Published: 2021-09-23 23:18 – Updated: 2022-08-11 16:54
VLAI?
Summary
Deno's static imports inside dynamically imported modules do not adhere to permission checks
Details

Impact

Modules that are dynamically imported through import() or new Worker might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected.

In effect an attacker in control of a (possibly remote) module in a programs module graph has been able to, irrespective of permissions: 1. initiate GET requests to arbitrary URLs on the internet (including LAN) and possibly read (parts of) the contents of these resources. 2. check for existence of arbitrary paths on the file system, and possibly read (parts of) the contents of these files.

In Deno 1.5.x (October 27th, 2020) and Deno 1.6.x (December 8th, 2020) the attacker module had to have been granted permissions to load dynamically through the network / fs read permission. Since Deno 1.7.x (January 19th, 2021) this vulnerability was able to be exploited in a fully sandboxed isolate (without any permissions). This vulnerability was not present in releases prior to 1.5.0.

Arbitrary non-GET requests, control over request headers, or file system writes are not possible through this vulnerability. Users of the deno_core, deno_runtime, or other deno_* crates are not affected. This is a Deno CLI only vulnerability.

We are relatively confident this was not abused in the wild, as by default Deno prints out a green "Download" message when remote imports are downloaded, and this would have caused suspicion if it occurred in the middle of a programs execution. This message can be silenced with the --quiet flag.

Patches

The vulnerability has been patched in Deno release 1.10.2. You can upgrade to the latest Deno version by running the deno upgrade command. The release is available through all official download channels.

Workarounds

There is no workaround for this issue.

For more information

If you have any questions or comments about this advisory: * Open an issue on the issue tracker * Discuss on Discord

Severity ?
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-23T21:13:15Z",
    "nvd_published_at": "2021-05-28T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nModules that are dynamically imported through `import()` or `new Worker` might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected.\n\nIn effect an attacker in control of a (possibly remote) module in a programs module graph has been able to, **irrespective of permissions**:\n1. initiate GET requests to arbitrary URLs on the internet (including LAN) and possibly read (parts of) the contents of these resources.\n2. check for existence of arbitrary paths on the file system, and possibly read (parts of) the contents of these files.\n\nIn Deno 1.5.x (October 27th, 2020) and Deno 1.6.x (December 8th, 2020) the attacker module had to have been granted permissions to load dynamically through the network / fs read permission. Since Deno 1.7.x (January 19th, 2021) this vulnerability was able to be exploited in a fully sandboxed isolate (without any permissions). This vulnerability was not present in releases prior to 1.5.0.\n\nArbitrary non-GET requests, control over request headers, or file system writes are not possible through this vulnerability. Users of the `deno_core`, `deno_runtime`, or other `deno_*` crates are not affected. This is a Deno CLI only vulnerability.\n\nWe are relatively confident this was not abused in the wild, as by default Deno prints out a green \"Download\" message when remote imports are downloaded, and this would have caused suspicion if it occurred in the middle of a programs execution. This message can be silenced with the `--quiet` flag.  \n\n### Patches\n\nThe vulnerability has been patched in Deno release 1.10.2. You can upgrade to the latest Deno version by running the `deno upgrade` command. The release is available through all official download channels. \n\n### Workarounds\n\nThere is no workaround for this issue.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue on [the issue tracker](https://github.com/denoland/deno)\n* Discuss on [Discord](https://discord.gg/deno)\n",
  "id": "GHSA-xpwj-7v8q-mcgj",
  "modified": "2022-08-11T16:54:03Z",
  "published": "2021-09-23T23:18:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-xpwj-7v8q-mcgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32619"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deno\u0027s static imports inside dynamically imported modules do not adhere to permission checks"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.