CERT VU#123335: Multiple Programming Languages Fail to Escape Arguments Properly in Microsoft Windows

[Alan Coopersmith <alan.coopersmith () oracle com>]

https://www.kb.cert.org/vuls/id/123335 announces:

> Vulnerability Note VU#123335
> Original Release Date: 2024-04-10 | Last Revised: 2024-04-10
>
> Overview
> ========
>
> Various programming languages lack proper validation mechanisms for
> commands and in some cases also fail to escape arguments correctly
> when invoking commands within a Microsoft Windows environment. The
> command injection vulnerability in these programming languages, when
> running on Windows, allows attackers to execute arbitrary code
> disguised as arguments to the command. This vulnerability may also
> affect the application that executes commands without specifying the
> file extension.
>
> Description
> ===========
>
> Programming languages typically provide a way to execute commands (for
> e.g., os/exec in Golang) on the operating system to facilitate
> interaction with the OS. Typically, the programming languages also
> allow for passing arguments which are considered data (or variables)
> for the command to be executed. The arguments themselves are expected
> to be not executable and the command is expected to be executed along
> with properly escaped arguments, as inputs to the command. Microsoft
> Windows typically processes these commands using a CreateProcess
> function that spawns a cmd.exe for execution of the command. Microsoft
> Windows has documented some of the concerns related to how these
> should be properly escaped before execution as early as 2011. See
> <https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way>.
>
> A vulnerability was discovered in the way multiple programming
> languages fail to properly escape the arguments in a Microsoft Windows
> command execution environment. This can lead confusion at execution
> time where an expected argument for a command could be executed as
> another command itself. An attacker with knowledge of the programming
> language can carefully craft inputs that will be processed by the
> compiled program as commands. This unexpected behavior is due to lack
> of neutralization of arguments by the programming language (or its
> command execution module) that initiates a Windows execution
> environment. The researcher has found multiple programming languages,
> and their command execution modules fail to perform such sanitization
> and/or validation before processing these in their runtime
> environment.
>
> Impact
> ======
>
> Successful exploitation of this vulnerability permits an attacker to
> execute arbitrary commands. The complete impact of this vulnerability
> depends on the implementation that uses a vulnerable programming
> language or such a vulnerable module.
>
> Solution
> ========
>
> Updating the runtime environment
> --------------------------------
>
> Please visit the Vendor Information section to see if your programming
> language Vendor has released the patch for this vulnerability and
> update the runtime environment that can prevent abuse of this
> vulnerability.
>
> Update the programs and escape manually
> ---------------------------------------
>
> If the runtime of your application doesn't provide a patch for this
> vulnerability and you want to execute batch files with user-controlled
> arguments, you will need to perform the escaping and neutralization of
> the data to prevent any intended command execution.
>
> Security researcher has more detailed information in the blog post
> which provides details on specific languages that were identified and
> their Status.

We've already seen some of the updates on this mailing list, including
notices for Rust & node.js.  For other languages, see the info on
https://www.kb.cert.org/vuls/id/123335#vendor-information and
https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/


--
        -Alan Coopersmith-                 alan.coopersmith () oracle com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris