But it got a 10/10 on the scoring system by Github.
The issue isn't actually too much related to the Rust core language itself, but rather how they handle scripts on Windows platform. So if you don't have a Windows program that runs Batch scripts, then it doesn't matter to you. I wonder how common it is to run Batch scripts in Rust?
if you don't have a Windows program that runs Batch scripts with untrusted arguments
This only matters when running the scripts with user inputs passed as arguments to the command, which I can't imagine being remotely common at all.
I don't think my company uses batch scripts anywhere, but if they did, it would probably be in the app installer for Windows or something.
Also, the reason this is a CVE is because Rust itself guarantees that calling commands doesn't evaluate shell stuff (but this breaks that guarantee). As far as I know C/C++ makes no such guarantee whatsoever.
Our bug is their status quo.
C++ has no guarantees built into stdlib but frameworks like Qt provide safe access - the ecosystem has options. C++ itself is quite a simple language, most of the power comes out of toolsets and frameworks built on top of it.
What are the chances Qt is affected by this issue too?
Vanishingly small. In Qt that'd have to be an issue in QStringList IIRC.
That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.
For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.
At least it's not a segfault, buffer overflow, or whatever else plagues C/C++ programs and is not easy to detect.
::: spoiler Anti Commercial AI thingy CC BY-NC-SA 4.0 :::
But it got a 10/10 on the scoring system by Github.
The issue isn't actually too much related to the Rust core language itself, but rather how they handle scripts on Windows platform. So if you don't have a Windows program that runs Batch scripts, then it doesn't matter to you. I wonder how common it is to run Batch scripts in Rust?
This only matters when running the scripts with user inputs passed as arguments to the command, which I can't imagine being remotely common at all.
I don't think my company uses batch scripts anywhere, but if they did, it would probably be in the app installer for Windows or something.
Also, the reason this is a CVE is because Rust itself guarantees that calling commands doesn't evaluate shell stuff (but this breaks that guarantee). As far as I know C/C++ makes no such guarantee whatsoever.
Our bug is their status quo.
C++ has no guarantees built into stdlib but frameworks like Qt provide safe access - the ecosystem has options. C++ itself is quite a simple language, most of the power comes out of toolsets and frameworks built on top of it.
What are the chances Qt is affected by this issue too?
Vanishingly small. In Qt that'd have to be an issue in QStringList IIRC.
That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.
For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.