rustsec-2021-0071
Vulnerability from osv_rustsec
Published
2021-06-12 12:00
Modified
2023-06-13 13:10
Summary
`grep-cli` may run arbitrary executables on Windows
Details

On Windows in versions of grep-cli prior to 0.1.6, it's possible for some of the routines to execute arbitrary executables. In particular, a quirk of the Windows process execution API is that it will automatically consider the current directory before other directories when resolving relative binary names. Therefore, if you use grep-cli to read decompressed files in an untrusted directory with that directory as the CWD, a malicious actor to could put, e.g., a gz.exe binary in that directory and grep-cli will use the malicious actor's version of gz.exe instead of the system's.

This is also technically possible on Unix as well, but only if the PATH variable contains .. Conventionally, they do not.

A DecompressionReader has been fixed to automatically resolve binary names using PATH, instead of relying on the Windows API to do it.

If you use grep-cli's CommandReader with a std::process::Command value on Windows, then it is recommended to either construct the Command with an absolute binary name, or use grep-cli's new resolve_binary helper function.

To be clear, grep-cli 0.1.6 mitigates this issue in two ways:

  • A DecompressionReader will resolve decompression programs to absolute paths automatically using the PATH environment variable, instead of relying on Windows APIs to do it (which would result in the undesirable behavior of checking the CWD for a program first).
  • A new function, resolve_binary, was added to help users of this crate mitigate this behavior when they need to create their own std::process::Command. For example, ripgrep uses grep_cli::resolve_binary on the argument given to its --pre flag.

While the first mitigation fixes this issue for sensible values of PATH when doing decompression search, the second mitigation is imperfect. The more fundamental issue is that std::process::Command is itself vulnerable to this.

To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "code-execution"
        ],
        "cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [
            "grep_cli::DecompressionReader::new"
          ],
          "os": [
            "windows"
          ]
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "grep-cli",
        "purl": "pkg:cargo/grep-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "0.1.6"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "CVE-2021-3013",
    "GHSA-g4xg-fxmg-vcg5"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "On Windows in versions of `grep-cli` prior to `0.1.6`, it\u0027s possible for some\nof the routines to execute arbitrary executables. In particular, a quirk of\nthe Windows process execution API is that it will automatically consider the\ncurrent directory before other directories when resolving relative binary\nnames. Therefore, if you use `grep-cli` to read decompressed files in an\nuntrusted directory with that directory as the CWD, a malicious actor to could\nput, e.g., a `gz.exe` binary in that directory and `grep-cli` will use the\nmalicious actor\u0027s version of `gz.exe` instead of the system\u0027s.\n\nThis is also technically possible on Unix as well, but only if the `PATH`\nvariable contains `.`. Conventionally, they do not.\n\nA `DecompressionReader` has been fixed to automatically resolve binary names\nusing `PATH`, instead of relying on the Windows API to do it.\n\nIf you use `grep-cli`\u0027s `CommandReader` with a `std::process::Command` value\non Windows, then it is recommended to either construct the `Command` with an\nabsolute binary name, or use `grep-cli`\u0027s new\n[`resolve_binary`](https://docs.rs/grep-cli/0.1.6/grep_cli/fn.resolve_binary.html)\nhelper function.\n\nTo be clear, `grep-cli 0.1.6` mitigates this issue in two ways:\n\n* A `DecompressionReader` will resolve decompression programs to absolute\npaths automatically using the `PATH` environment variable, instead of relying\non Windows APIs to do it (which would result in the undesirable behavior of\nchecking the CWD for a program first).\n* A new function, `resolve_binary`, was added to help users of this crate\nmitigate this behavior when they need to create their own\n`std::process::Command`. For example,\n[ripgrep uses `grep_cli::resolve_binary`](https://github.com/BurntSushi/ripgrep/blob/7ce66f73cf7e76e9f2557922ac8e650eb02cf4ed/crates/core/search.rs#L119-L122)\non the argument given to its `--pre` flag.\n\nWhile the first mitigation fixes this issue for sensible values of `PATH`\nwhen doing decompression search, the second mitigation is imperfect. The more\nfundamental issue is that `std::process::Command` is itself vulnerable to this.",
  "id": "RUSTSEC-2021-0071",
  "modified": "2023-06-13T13:10:24Z",
  "published": "2021-06-12T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/grep-cli"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0071.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/BurntSushi/ripgrep/issues/1773"
    }
  ],
  "related": [],
  "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": "`grep-cli` may run arbitrary executables on Windows"
}


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.