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 the issue is caused by rust not escaping arguments
That Windows API is terrible. There isn’t a way to have the escaping done for you. Further, there is not an API where you do not need to do the escaping. There is no documentation on what kind of escaping is needed.
That’s 100% a rust problem. Trusting another system to sanitize your input is about the dumbest thing I’ve ever heard. Windows being shitty isn’t an excuse for the language being shitty as well.
Except it’s actually an “Every language and library that provides this feature” problem because literally no one was aware that this sanitization problem even existed, and Rust is among the first to actually fix it.
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.
Rust has an API they provide which allows for calling batch files. This API has a flaw. The rust team acknowledged, and fixed the flaw.
If you provide an API it should be safe to use. If you don’t provide an API (C/C++) then its up to the programmer to implement it themselves. If that implementation has an issue in how it parses command line args, you would fault the developer of the parsing functionality for not escaping correctly. Thus the developers of the rust api which handles parsing command line arguments has a fault in its implementation.
ed. quick additional example. SQL injection can still be written today; if you just take arbitrary user input and execute it on a db, you open yourself up to exploitation. DB engines provide ways to parameterise queries to prevent this.
If the parameterisation routine allowed for sql injection exploits because it didn’t handle the inputs correctly, who would be at fault?
The `Command::arg` and `Command::args` APIs state in their documentation that the arguments will be passed to the spawned process as-is, regardless of the content of the arguments, and will not be evaluated by a shell. This means it should be safe to pass untrusted input as an argument.
It goes onto discuss how this is more complex to do in windows, but the rust team chose to implement this, and as a consequence this implementation has an issue.
That forces the standard library to implement custom escaping for arguments passed to batch files. Unfortunately it was reported that our escaping logic was not thorough enough, and it was possible to pass malicious arguments that would result in arbitrary shell execution.
The entire problem with cmd.exe was not known and so obviously not documented when the Rust standard library developers were implementing the API, and the same goes for the standard library developers of every other language. Rust was among the first to fix this problem in their API, with many other languages opting to just document the issues instead of actually protecting users from it.
To take all this information and distill it down to trumpeting “Rust has a CVSS level 10 security vulnerability!!” without context is stupidity at best and maliciously disingenuous at worst.
Nitpicking whether the statement can be construed as true within a certain framing just demonstrates malicious intent when the reality is that users of Go, Python, and Java, whose standard libraries have taken a position of Won’t Fix, are in a FAR more dangerous position than Rust users who are actually in the safest position of anyone in any language ecosystem besides perhaps Haskell.
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.
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.
WinAPIs are rife with weirdness like this that has stuck around for backward compatibility reasons. The day MS finally kills win32 will be the day Windows’ security improves tenfold.
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.
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/
That Windows API is terrible. There isn’t a way to have the escaping done for you. Further, there is not an API where you do not need to do the escaping. There is no documentation on what kind of escaping is needed.
It’s not a Rust problem.
The Windows API is the direct access to OS functions. If you’re using the API it’s your responsibility to do it securely and protect your users.
deleted by creator
That’s 100% a rust problem. Trusting another system to sanitize your input is about the dumbest thing I’ve ever heard. Windows being shitty isn’t an excuse for the language being shitty as well.
Except it’s actually an “Every language and library that provides this feature” problem because literally no one was aware that this sanitization problem even existed, and Rust is among the first to actually fix it.
deleted by creator
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.
Rust has an API they provide which allows for calling batch files. This API has a flaw. The rust team acknowledged, and fixed the flaw.
If you provide an API it should be safe to use. If you don’t provide an API (C/C++) then its up to the programmer to implement it themselves. If that implementation has an issue in how it parses command line args, you would fault the developer of the parsing functionality for not escaping correctly. Thus the developers of the rust api which handles parsing command line arguments has a fault in its implementation.
ed. quick additional example. SQL injection can still be written today; if you just take arbitrary user input and execute it on a db, you open yourself up to exploitation. DB engines provide ways to parameterise queries to prevent this.
If the parameterisation routine allowed for sql injection exploits because it didn’t handle the inputs correctly, who would be at fault?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-24576
It goes onto discuss how this is more complex to do in windows, but the rust team chose to implement this, and as a consequence this implementation has an issue.
The entire problem with cmd.exe was not known and so obviously not documented when the Rust standard library developers were implementing the API, and the same goes for the standard library developers of every other language. Rust was among the first to fix this problem in their API, with many other languages opting to just document the issues instead of actually protecting users from it.
To take all this information and distill it down to trumpeting “Rust has a CVSS level 10 security vulnerability!!” without context is stupidity at best and maliciously disingenuous at worst.
Nitpicking whether the statement can be construed as true within a certain framing just demonstrates malicious intent when the reality is that users of Go, Python, and Java, whose standard libraries have taken a position of Won’t Fix, are in a FAR more dangerous position than Rust users who are actually in the safest position of anyone in any language ecosystem besides perhaps Haskell.
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:
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.
I explained it elsewhere, but basically: an API that needs undocumented escaping doesn’t immediately make you think that the API has huge issues?
WinAPIs are rife with weirdness like this that has stuck around for backward compatibility reasons. The day MS finally kills win32 will be the day Windows’ security improves tenfold.
If you read it more attentively, no, it does say that.
I dislike all the “rewrite it in Rust to be secure” bros, but not such a case here.