How so? This exploit requires running a shell command in a way that permits an attacker to control the arguments provided. That doesn't seem like it would be particularly common in build scripts.
I'm thinking an xz-style attack where a malicious actor submits an "improvement" with an innocuous-looking change to the build script that ends up running arbitrary commands. Running a batch script seems like a reasonable thing for a build script to do (e.g. to run something like i18n or whatever), and a lot of project devs may not know much about how batch scripts work (many devs are more familiar with Linux-compatible shell scripts), so it could slip through. The batch script itself could be innocuous and thus not be caught by a reviewer.
So I don't think it's unreasonable to think a developer could sneak in an exploit with "temporary code" to improve some part of the build process on Windows.
Were there actually any real-world use-cases affected by this? Do any of them not deserve to be named and shamed irregardless of this vulnerability?
If it was up to me, I would nuke the cmd custom implementation, leave some helpful compile error messages behind, and direct users to some 3rd party crates to choose from.
Edit: to be clear, there is no "custom implementation" of cmd itself, nor is the problem exclusive to Rust. This is a problem with the Windows cmd itself.
10 Comments
myotherself@lemmings.world · 12 pts · 2y
Tl;dr:
std::process::Commandis vulnerable to shell injection if you invokecmd.exeor*.{cmd,bat}on Windows.sugar_in_your_tea@sh.itjust.works · 2 pts · 2y
This sounds like a pretty big deal for crates with custom build.rs files.
BatmanAoD@programming.dev · 11 pts · 2y
How so? This exploit requires running a shell command in a way that permits an attacker to control the arguments provided. That doesn't seem like it would be particularly common in build scripts.
sugar_in_your_tea@sh.itjust.works · 2 pts · 2y
I'm thinking an xz-style attack where a malicious actor submits an "improvement" with an innocuous-looking change to the build script that ends up running arbitrary commands. Running a batch script seems like a reasonable thing for a build script to do (e.g. to run something like i18n or whatever), and a lot of project devs may not know much about how batch scripts work (many devs are more familiar with Linux-compatible shell scripts), so it could slip through. The batch script itself could be innocuous and thus not be caught by a reviewer.
Schmeckinger@feddit.de · 1 pts · 2y
But there is no reason to use a script, when you have a build.rs anyways. Since pretty much everything the script can do build.rs can do better.
sugar_in_your_tea@sh.itjust.works · 3 pts · 2y
That's not going to be particularly feasible when generating bindings and other complex build processes. For example, the Qt bindings run shell commands as part of the build.rs. As does gettext-rs.
So I don't think it's unreasonable to think a developer could sneak in an exploit with "temporary code" to improve some part of the build process on Windows.
anlumo@feddit.de · 1 pts · 2y
I’d instantly reject such an approach. Find a better way to do things.
BB_C@programming.dev · 1 pts · 2y
Were there actually any real-world use-cases affected by this? Do any of them not deserve to be named and shamed irregardless of this vulnerability?
If it was up to me, I would nuke the cmd custom implementation, leave some helpful compile error messages behind, and direct users to some 3rd party crates to choose from.
Moussx@programming.dev · 6 pts · 2y
Doing such a regression on a Tier 1 target would be a really big blow to the language's reputation imo
BatmanAoD@programming.dev · 5 pts · 2y
What custom implementation? The escaping logic?
Edit: to be clear, there is no "custom implementation" of
cmditself, nor is the problem exclusive to Rust. This is a problem with the Windowscmditself.