crates/grep-cli: add advisory for arbitrary binary execution on Windows

Ref BurntSushi/ripgrep#1773

crates/grep-cli/RUSTSEC-0000-0000.md

@@ -0,0 +1,42 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "grep-cli"
+date = "2021-06-12"
+url = "https://github.com/BurntSushi/ripgrep/issues/1773"
+categories = ["code-execution"]
+keywords = ["windows", "ripgrep", "PATH", "arbitrary", "binary"]
+aliases = ["CVE-2021-3013"]
+
+[versions]
+patched = [">= 0.1.6"]
+unaffected = []
+
+[affected]
+#arch = ["x86"]
+os = ["windows"]
+functions = { "grep_cli::DecompressionReader::new" = ["< 0.1.6"] }
+```
+
+# RustSec Advisory Template - Advisory Title Goes Here
+
+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`](https://docs.rs/grep-cli/0.1.6/grep_cli/fn.resolve_binary.html)
+helper function.