sugar_in_your_tea@sh.itjust.works
on 10 Apr 2024 00:30
nextcollapse
This sounds like a pretty big deal for crates with custom build.rs files.
BatmanAoD@programming.dev
on 10 Apr 2024 06:14
nextcollapse
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
on 10 Apr 2024 07:27
collapse
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
on 11 Apr 2024 07:04
collapse
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
on 11 Apr 2024 07:47
collapse
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.
I’d instantly reject such an approach. Find a better way to do things.
BB_C@programming.dev
on 10 Apr 2024 06:29
nextcollapse
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
on 10 Apr 2024 14:26
nextcollapse
Doing such a regression on a Tier 1 target would be a really big blow to the language’s reputation imo
BatmanAoD@programming.dev
on 10 Apr 2024 16:02
collapse
What custom implementation? The escaping logic?
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.
myotherself@lemmings.world
on 10 Apr 2024 08:33
collapse
Tl;dr: std::process::Command is vulnerable to shell injection if you invoke cmd.exe or *.{cmd,bat} on Windows.
threaded - newest
This sounds like a pretty big deal for crates with custom build.rs files.
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.
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.
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.
I’d instantly reject such an approach. Find a better way to do things.
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.
Doing such a regression on a Tier 1 target would be a really big blow to the language’s reputation imo
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.Tl;dr:
std::process::Commandis vulnerable to shell injection if you invokecmd.exeor*.{cmd,bat}on Windows.