BatBadBut: You can't securely execute commands on Windows
BatBadBut: You can't securely execute commands on Windows
Introduction Hello, I’m RyotaK ( @ryotkak ), a security engineer at Flatt Security Inc. Recently, I reported multiple vulnerabilities to several programming languages that allowed an attacker to perform command injection on Windows when the specific conditions were satisfied. Today, affected vendors...
You're viewing a single thread.
i’m not understanding how this is supposed to be so severe. if an attacker has the ability to change the arguments to a
CreateProcesscall, aren’t you hosed already? they could just change it to invoke any command or batch file they wanted.That’s entirely dependent on the application. In many cases the command would be hard-coded in the application, in which case you’re right. But some applications have good reasons to pass user-supplied arguments to scripts. Imagine a case where an application generates PDFs through a batch script, for instance. It might make sense to let users specify the filename, but then it does need proper escaping. In such a case it’s a huge risk if it turns out the escaping rules suddenly changed because Windows silently invoked
cmd.exeunder the hood.even in your hypothetical of a file name passed in through the args, either the attacker has enough access to run said tool with whatever args they want, or, they have taken over that process and can inject whatever args they want.
either attack vector requires a prior breach of the system. you’re owned either way.
the only way this actually works as an exploit is if there are poorly written services out there that blindly call through to
CreateProcessthat take in user sourced input without any sanitization, which if you’re doing that then no duh you’re gonna have a bad time.cmd.exeis always going to be invoked if you’re executing a batch script, it’s literally the interpreter for .bat files. the issue is, as usual, code that might be blindly taking user input and not even bothering to sanitize it before using it.
You wouldn't be hosed on Linux for example. Note that this applies to the arguments to the program, not just the program itself.
In other words if I do
run(["echo", untrusted_input])it would be totally fine on Linux.honestly i wouldn’t trust your linux example at all, what happens with
run([“echo”, “&& rm -rf /“])It would print “&& rm -rf /“ and nothing bad would happen.