Critical 'BatBadBut' Rust Vulnerability Exposes Windows Systems to Attacks
Critical 'BatBadBut' Rust Vulnerability Exposes Windows Systems to Attacks
A severe vulnerability (CVE-2024-24576) in the Rust standard library could lead to command injection attacks on Windows systems.
Once again this is not a Rust vulnerability.
This is a Windows vulnerability and Rust is simply the first set of tools to implement a workaround - since Microsoft can't do it without breaking backwards compatibility.
Somehow the narrative has turned into negative PR for Rust when in fact they are handling this vulnerability better than anyone else in the industry.
"The Rust standard library did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command API,"
If the issue is caused by rust not escaping arguments, and fixed by rust properly escaping arguments, how is it not a rust issue?
Because Rust is not the only language that made this faulty assumption. It is an issue that affects Rust's stdlib, just like it is an issue that affects Python's stdlib and other libraries. In fact this was first reported as a vulnerability to yt-dlp (where it was actually exploitable) and then discovered it applied to many other libraries (where the exploitability is highly dependent on how the feature is used).
Rust here is only used as clickbait because of its aim to be "safe", but its position is no different from other languages.
If you read the article from the researcher that discovered the vulnerability you'll see they never call out Rust in particular, only as part of a list of languages that are affected. https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/
If the issue exists in the standard library of every language that provides this capability and Rust's standard library is the first to fix it, how is it a Rust issue?
It would be more accurate to say that it's an issue in almost every language EXCEPT Rust at this point.
The only reason it isn't being called a C or C++ issue is because their standard libraries don't even attempt to offer this capability. But you can bet that all sorts of C/C++ libraries that do offer this, like Qt, will also be having this issue.
Because when it's a rust issue, clearly something else is at fault.
Frankly I'm more concerned about Java's wont fix
If windows does not document features of their API that would require escaping, how is it a Rust issue they had no way of knowing escaping is necessary? Its Windows whose API is not following the documented behavior/has undocumented behavior.
Both the article and the CVE description point to how Rust handles escaping for CMD arguments. If it's not a Rust issue then can you explain?
Because this is the status of the bug across the standard libraries of various languages, per this article and others:
- Erlang (documentation update)
- Go (documentation update)
- Haskell (patch available)
- Java (won’t fix)
- Node.js (patch will be available)
- PHP (patch will be available)
- Python (documentation update)
- Ruby (documentation update)
Notably C and C++ are missing from this list because their standard libraries don't even offer this capability. Half of these standard libraries are responding to the issue by just warning you about it in the function documentation. Rust is one of the few that actually prevents the attack from happening.
The original BatBadBut bug report used JavaScript to illustrate the vulnerability.
Jeez, I love Rust as much as the next guy, but people in this thread are getting weirdly defensive about it.
Yeah, so some standard libraries don't offer that particular feature, what's the point? They also don't "offer" that vulnerability then. I can't even twist my mind around to see what kind of argument this is supposed to be.
Yes, the Windows API is a cesspool in many places, and yes, other standard libraries might still be affected by a similar issue, but Rust's stdlib also fucked it up. If you offer an interface, it's your responsibility to ensure it does what you claim, not matter how batshit insane the underlying 3rd party implementation might be. If you can't do that, I'd actually prefer if you didn't offer said interface. In any case, they handled the issue, and now it's hopefully fixed. That's fine, commendable job.
I agree the headline could have been worded differently, but we can still use Rust, it's still a great language, great goals etc., why try so hard to make it look like there wasn't an issue?
You are not your standard library, you have not been defiled. You can still open that bedside drawer and put on your little purity ring every morning if that's your thing, we won't judge you, just don't be all weird about it.
You could not have worded that more condescendingly. The issue here is that Rust is singled out for no more apparent reason than making for a clickbaity headline. The underlying Windows API function requires undocumented escaping to prevent this exploit, Microsoft won't fix that because it breaks compatibility, pretty much every programming language with a standard library that provides access to it is affected - Java won't even fix it, others have updated their documentation. Rust is the first to actually implement a fix for a vulnerability that's ultimately caused by Windows and gets called out for it for some reason. Of course people are going to get defensive about it. As they do every time a stupid headline gets published.
You are right, I was kind of a dick about it. I even realized that, deleted the most offensive lines twice and then still sent it.
On top of having a bad day in general, I encountered countless similar responses in other places, some of which were so borderline in(s)ane and over the top that I was... let's just say taken aback.
As I said, the headline could have been better, whole article honestly, same goes for the reaction of the Rust community though.
As for my own replies, I'll probably follow my gut feeling next time when having second thoughts about posting.
Does this have any implications for Rustdesk? I suspect not, but not 100% sure.