Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "major security vulnerability found in rust (over hyped?)" video.

  1. The only reason this has CVSS base score 10/10 is because the "Security Researcher" that reported this issue wanted to have "Rust 10/10 CVE" in their CV. This is not a security vulnerability in Rust but in the piece of software that uses Rust to launch a .bat file and gives it the user input as parameter. If I write a piece of PHP code that executes "bash -c $escaped_userinput" where $escaped_userinput = escapeshellarg($userinput) call, it's not a security vulnerability in PHP nor bash but in my code only. Windows .bat files simply execute strings even without "-c" flag.
    1
  2. I would argue that this is actually a security vulnerability in Windows .bat execution instead of vulnerability in Rust. Unlike in POSIX shells where the command line is parsed and executed by the shell and arg() correctly encodes the arguments, Windows .bat execution takes the correctly encoded user input as a single parameter and then internally make another interpretation of the arguments! The reason windows binaries do this is because their command line is too stupid to do any processing so all processing must be re-implemented by every program you run. And as usual, you MUST encode all untrusted user input in a way that's appropriate for the context and for this case, you need double encoding: encode once for .bat argument syntax and another time for the Rust Command syntax where the arg() is the correct solution. This is similar to having to encode a piece of user input as JavaScript string and add another encoding step to encode the JavaScript as part of HTML input. Failing to do either of the two required steps results in injection attack. Current Rust doesn't have a "bugfix" for this vulnerability. Instead they fixed the documentation to explain this to Windows developers that may not be aware of this Windows behavior: "On Windows use caution with untrusted inputs. Most applications use the standard convention for decoding arguments passed to them. These are safe to use with arg. However some applications, such as cmd.exe and .bat files, use a non-standard way of decoding arguments and are therefore vulnerable to malicious input. In the case of cmd.exe this is especially important because a malicious argument can potentially run arbitrary shell commands." On Windows, there are no generic safe way to encode command line arguments as data. The correct encoding depends on the command you execute. And as a result, arg() cannot be modified to have generic safe encoding for all commands.
    1
  3. CVSS scores are interesting because recent XZ Utils backdoor was rated as 10/10, too, but it was 10 only for the attacker that knows the not-yet-published private key that matches the public key in the backdoor. For everybody else the CVSS score should have been maybe 3/10 because the backdoor can be used to increase CPU load and cause remote DoS because of consuming CPU resources.
    1
  4.  @arthurmoore9488  It's not eve a flaw in how cmd.exe parses arguments. It's a quirk of Windows .bat execution. Pretending that this is a Rust remote execution bug is like saying that if you write Rust code on Linux that looks like this Command::new("bash").arg("-c").arg(userinput).output().expect(); is a remote execution vulnerability! The fact that "bash -c" takes the rest of the arguments (given as text data!) as commands is not a vulnerability in Rust. The fact that Windows .bat files execute arguments without the "-c" flag is not a vulnerability of .bat files either. It's just a demonstration that the developer writing code that runs .bat file MUST understand the behavior of .bat files.
    1