Critical Rust flaw enables Windows command injection attacks
Critical Rust flaw enables Windows command injection attacks
www.bleepingcomputer.com
Critical Rust flaw enables Windows command injection attacks
18 comments
-
-
This isn't Rust specific. It's really difficult to securely start a command in Windows. I highly recommend to read https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/.
-
I'm honestly surprised windows can even exist at this point.
It's mind-boggling to me that people would dedicate their lives to learning that system when it's such a shoddy piece of crap.
It's amazing what a motivator money can be.
-
-
"not so safe now are you Rust" ~C, probably
-
It's not Rust, the language or even Windows.
It's if you write a program that allows the end user to call a command prompt and don't carefully sanitize the input, bad things could happen.
I mean, maybe Windows could do something different but if you wrote JavaScript that takes text input from a webpage and pass it to "sudo bash ##commands", you're going to have a bad time.
It's complete click bait because Rust has a reputation for security.
-
It's definitely not Rust's fault, but it's kinda Windows' one and cmd.exe escape logic... It's really difficult to write logic that will correctly escape any argument given to it, cmd.exe really is a pain to deal with :/
The Rust security team faced a significant challenge when dealing with cmd.exe's complexity since they couldn't find a solution that would correctly escape arguments in all cases.
As a result, they had to improve the robustness of the escaping code and modify the Command API. If the Command API cannot safely escape an argument while spawning the process, it returns an InvalidInput error.
"If you implement the escaping yourself or only handle trusted inputs, on Windows you can also use the CommandExt::raw_arg method to bypass the standard library's escaping logic," the Rust Security Response WG added.
I get that in situations where they can't safely escape a parameter they'll just stop with an error, which sound as sane as one could go with this!
-
-
-
I’m no Windows expert but I wonder why they don’t offer a “Windows Now” type product that breaks backwards compatibility but is more secure. Something that doesn’t even come with cmd.exe because Powershell exists. (Not that it would solve the issue in the article. This is more an aside.) Windows RT was probably not that. From what I understand, it was a “Windows But Weirdly Limited” product. I mean full Windows that can run reasonably modern software but does away with all the backwards compatibility stuff only certain businesses need.
Apple is ruthless about that and it doesn’t seem to hurt them. Linux distros barely bother because you can always find a way to run an old version if you really want to. It’s kind of neat that Windows can still run Excel 1.0 or whatever but as a non-Windows user, it seems like they could break with the past and fix a lot of security issues for a fraction of what they’re spending on A.I. PowerPoints or whatever.
-
That was what 10X was supposed to be. It was supposed to be practically a full rewrite of the OS to shake off all the legacy cruft with support for existing Win32 apps through containerization. It was dropped along with the Surface Neo and they shifted their focus to Win 11 instead which is a real shame.
-
Windows's entire selling point is backwards-compatibility, maybe except the ARM version.
-
Yes, one of the factors that contributed to the demise of Windows Mobile was the lack of backwards-compatibility for apps between 7, 8, an 10.
-
-
-
Feels like the Spanish flu all over
-
Damn. I love the game.
-
Are that’s bad, and Rust was generally thought to be good for security.
-
"Batch files"
-
18 comments
Funny how the headline makes it sound like a Rust specific problem, as if the Rust language is unsafe or the core team was incompetent, but then other affected language standard libraries include
So actually this is a vulnerability that originates in Windows, and Rust and Haskell are the only languages that are actually protecting users from it as of right now, with Node.js and PHP to follow.