18
votes
Critical vulnerability in Rust's Command library allows for command injection when using its API to invoke batch scripts with arguments on Windows systems (CVE-2024-24576)
Link information
This data is scraped automatically and may be incorrect.
- Title
- Critical Rust flaw enables Windows command injection attacks
- Authors
- Sergiu Gatlan
- Word count
- 450 words
Note that the CVE has been assigned the maximum CVSS base score of 10/10, but keep in mind, that it is still a rather specific vulnerability. It only affects software that uses the Rust's Command library to execute batch scripts with arguments on Windows. Still very interesting find though.
This is basically what its Nickname 'BatBadBut' stands for as well: "It’s about batch files and bad, but not the worst."
Also note that other programming languages are also affected in one way or another, but I haven't really looked into that as of yet. The (german) Heise article [1] specifically cites the CVE's discoverer RyotaK as listing Erlang, Go, Haskell, Java, Node.js, PHP, Python, and Ruby in addition to Rust.
[1] https://www.heise.de/news/BatBadBut-Kritische-Befehlsschmuggel-Luecke-in-Windows-etwa-in-Rust-9680576.html
For anyone else wondering why everyone's reporting the vulnerability with regards to rust, despite multiple programming languages being affected:
It appears the news initially gained traction when CVE-2024-24576 affecting the rust programming language was rated 10.0 critical, and a respective Rust security advisory [1] was published. The aspects of BatBadBut affecting other programming languages and tools appear to be covered by different CVEs (e.g. CVE-2024-1874, CVE-2024-22423, CVE-2024-3566) that have received a different, less severe rating.
This may become a bit clearer when reading the vulnerability disclosure by RyotaK on the Flatt Security Blog [2]. It appears that the root cause of the vulnerability are common but wrong assumptions about how the
CreateProcess()function in Windows (which implicitly callscmd.exe) escapes its argument strings.Obviously different programming languages have written different wrappers for that function, which run into that problem in different ways. So while for some languages a documentation change may suffice to correct the wrong assumption (although I'm not sure wether that's the nicest solution given that it delegates the problem to developers further down the pipeline if I understood that correctly), other languages with a high level of abstraction and many security guarantees may actually need to change how they implemented the wrapper and its respective API. This probably also explains why the Rust CVE was rated as so severe, given that Rust's main selling points are basically security/safety guarantees for developers.
[1] https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
[2] https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/
I'm a bit confused by the line that mentions Java won't be fixing this vulnerability. Is it because Java is just accepting the risk, or does it only apply to older versions or something?
Yeah, as of right now I'm not sure what to make of that as well. But I also haven't had a chance to look into how each of the listed languages is affected by the vulnerability.