Comments by "Edward Cullen" (@edwardcullen1739) on "Rust Vulnerability With Windows" video.

Or... Just don't pass to the shell?!?!? Maybe I'm old or something, but I don't understand why people are still doing this. I avoid it like the plague, even porting logic from 3rd-party batch files into a proper language, simply because it's a saver in the end.
2
I don't understand this CVE. It is NEVER safe to pass "untrusted" arguments to a shell. Regardless of the issues with Rust's implementation, if you're passing unsanitised user input, you've already failed.
2
@timseguine2 Ah, I get you. What I'm trying to let people know is that "passing user-provided input to a shell" is a well-known vulnerability, with a long and shameful history. Remember the Bash CGI-bin crisis a few years ago? It doesn't matter whether it's Unix or Windows or how the OS parses the arguments - the only safe way to invoke a sub-process shell is to thoroughly vet any user input before passing it. The sub-process shell is the gun. Any parsing done by Rust or C runtime is only a trigger guard, not a safety. A .bat file is interpreted by the shell, as a .sh file would be (though, the precise method for doing so is different, which is where this issue arrises).
2
@timseguine2 Hmm... I guess I need to dive into the Rust docs to get the full picture, but this still doesn't answer my question... There all sorts of (ba)sh escaping and interpretation issues that could be exploited to result in arbitrary code execution. My issue is that passing untrusted arguments to any shell process is, definitionally, suicidal and no one seems to be talking about this. It's like saying "pulling the trigger while pointing a gun at yourself is bad", when we should be saying "you shouldn't be pointing a gun at yourself, full stop!"
1
@rusi6219 Dunno if my full reply is delayed, or I tripped the bots, but, in short, invoking a shell with user-supplied input, is always a gun. Calling a .bat file is invoking a shell, as would calling a .sh. Believing any runtime (Rust, C, whatever) can make it not a gun is a mistake; they are, at best, a trigger guard.
1
@timseguine2 Agreed. The main issue is "user supplied input". Constraining this is incredibly difficult, unless you have a very strict grammar (for the non-programmers, this means you have a very limited list of valid inputs that you can check against). Even designing a grammar is hard, as it's surprisingly easy to create one that is ambiguous (flashbacks to Compiler Engineering at Uni 😅). And that is assuming that you set out to formally create a grammar, as opposed to accidentally manifesting one as you develop your product! 😂
1
@joseoncrack They have, to an extent - there is PowerShell - but Microsoft will not break backwards compatibility. As I imply, this is more a developer problem than a Microsoft problem... I have reverse-engineered and re-implemented many .bat files to avoid this kind of problem. But doing this requires time, patience and a deep understanding of "no matter how long it takes, it's better than the alternative." 😅😂
1