Add CVE-2024-24576 blog post

posts/2024-04-09-cve-2024-24576.md

@@ -0,0 +1,76 @@
+---
+layout: post
+title: "Security advisory for the standard library (CVE-2024-24576)"
+author: The Rust Security Response WG
+---
+
+The Rust Security Response WG was notified that the Rust standard library did
+not properly escape arguments when invoking batch files (with the `bat` and
+`cmd` extensions) on Windows using the [`Command`][1] API. An attacker able to
+control the arguments passed to the spawned process could execute arbitrary
+shell commands by bypassing the escaping.
+
+The severity of this vulnerability is **critical** if you are invoking batch
+files on Windows with untrusted arguments. No other platform or use is
+affected.
+
+This vulnerability is identified by CVE-2024-24576.
+
+## Overview
+
+The [`Command::arg`][2] and [`Command::args`][3] APIs state in their
+documentation that the arguments will be passed to the spawned process as-is,
+regardless of the content of the arguments, and will not be evaluated by a
+shell. This means it should be safe to pass untrusted input as an argument.
+
+On Windows, the implementation of this is more complex than other platforms,
+because the Windows API only provides a single string containing all the
+arguments to the spawned process, and it's up to the spawned process to split
+them. Most programs use the standard C run-time argv, which in practice results
+in a mostly consistent way arguments are splitted.
+
+One exception though is `cmd.exe` (used among other things to execute batch
+files), which has its own argument splitting logic. That forces the standard
+library to implement custom escaping for arguments passed to batch files.
+Unfortunately it was reported that our escaping logic was not thorough enough,
+and it was possible to pass malicious arguments that would result in arbitrary
+shell execution.
+
+## Mitigations
+
+Due to the complexity of `cmd.exe`, we didn't identify a solution that would
+correctly escape arguments in all cases. To maintain our API guarantees, we
+improved the robustness of the escaping code, and changed the `Command` API to
+return an [`InvalidInput`][4] error when it cannot safely escape an argument.
+This error will be emitted when spawning the process.
+
+The fix will be included in Rust 1.77.2, to be released later today.
+
+If you implement the escaping yourself or only handle trusted inputs, on
+Windows you can also use the [`CommandExt::raw_arg`][5] method to bypass the
+standard library's escaping logic.
+
+## Affected Versions
+
+All Rust versions before 1.77.2 on Windows are affected, if your code or one of
+your dependencies executes batch files with untrusted arguments. Other
+platforms or other uses on Windows are not affected.
+
+## Acknowledgments
+
+We want to thank RyotaK for responsibly disclosing this to us according to the
+[Rust security policy][6], and Simon Sawicki (Grub4K) for identifying some of
+the escaping rules we adopted in our fix.
+
+We also want to thank the members of the Rust project who helped us disclose
+the vulnerability: Chris Denton for developing the fix; Mara Bos for reviewing
+the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish
+Goregaokar and Josh Stone for coordinating this disclosure; Amanieu d'Antras
+for advising during the disclosure.
+
+[1]: https://doc.rust-lang.org/std/process/struct.Command.html
+[2]: https://doc.rust-lang.org/std/process/struct.Command.html#method.arg
+[3]: https://doc.rust-lang.org/std/process/struct.Command.html#method.args
+[4]: https://doc.rust-lang.org/std/io/enum.ErrorKind.html#variant.InvalidInput
+[5]: https://doc.rust-lang.org/std/os/windows/process/trait.CommandExt.html#tymethod.raw_arg
+[6]: https://www.rust-lang.org/policies/security