Windows Command Escape Vulnerability - Critical CVE ... or is it?

Critical! ... or is it?

CVE-2024-24576 is a freshly reported 10/10 critical CVE affecting Rust, Python, and many other programming languages on Windows that, if exploited, can allow a malicious user to execute arbitrary code as the current user. The 10/10 rating is the worst severity that can be given to a CVE. However, of 9 affected programming languages, 5 have chosen to either not fix the CVE or fix it only by updating their documentation. Let's take a look at this vulnerability, which appears to take advantage of programming languages improperly escaping arguments while creating sub-processes, understand how it's performed, and see why so many languages are choosing not to fix it.

SUPPORT ME ⭐
---------------------------------------------------
Sign up on Patreon to get your donor role and early access to videos!

Feeling generous but don't have a Patreon? Donate via PayPal! (No sign up needed.)

Want to donate crypto? Check out the rest of my supported donations on my website!

Top patrons and donors: Jameson, Laura M, Dragos C, Vahnekie, Neel R, Matt R, Johan A, Casey G, Mark M, Mutual Information, Pi

BE ACTIVE IN MY COMMUNITY 😄
---------------------------------------------------

CHAPTERS
---------------------------------------------------
0:00 Intro
1:43 How it happens
3:21 Subprocesses and shell=True
5:24 The CVE doesn't use shell=True
6:23 Diving into the subprocess module
7:31 The meaning of running a batch file
8:42 A compromise fix

[MrChaoS]

java chad move "won't fix"

[jamesarthurkimbell]

Heartening to see someone look into this and get a real sense of what's going on instead of shooting off a video last week when the news was hot

[AntonioZL]

0:15 "Rust is a programming language" 🗣🗣🗣🗣🔥🔥🔥

Btw, I found out that ChatGPT can write batch files *literally* yesterday while using the task scheduler on Windows to schedule the execution of a Python script on one of the PCs at my job, so I'm technically part of the people still using it.

[GrubK]

This can still be a big problem; look at npm or VSCode: these typically get called using `npm` and `code`, but those are batch files on Windows ("npm.cmd" and "code.cmd"). So if you use these you cannot do it using `npm` or `code` in path anymore, or you could be exploited. Some might not even realize they were calling a batch file for these! THAT is why this is such a big deal!

Ofc the solution is for these programs to NOT use batch file wrappers, but for now you have to manually search for the actual executable and always use an explicit ".exe" extension

[Cucuska]

Quite weird that the Win API doesn't have a way of processing an array of arguments.

[dave_jones]

Thank you James, I can’t wait to have to send this video to my OIS when they tell me I need to abandon python. I keep telling them the real thing we need to abandon are windows servers!

[TheFerdi]

The problem is that unlike 'sh -c' or 'bash -c' on Linux, which only process one argument as a shell script and pass the rest as unevaluated arguments, 'cmd /c' actually parses all following arguments as a single shell command. There is no way to pass untrusted unevaluated arguments to 'cmd /c'.

Without _knowing_ whether the target is a batch script or cmd.exe (or even a copy of cmd.exe!), it's impossible for a programming language API to correctly escape arguments here.

The backwards-compatible solution would be for Microsoft to provide a new flag for cmd.exe that behaves like Linux's 'sh -c' and only processes one argument as a shell script, and for batch script invocations to use this new flag if a certain compatibility option is not set (in settings or registry or whereever)

[echidne]

the clearer explanation i see so far. Bravo !!

[johnsmith]

here's the part that's questionable to me:
```
To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.
```
Is what the documentation says, and what it actually does is run cmd for you regardless.

[whamer]

this is my exact reaction to seeing this CVE. i was like "isnt this just, expected behavior?" lmao

[KvapuJanjalia]

If you are passing untrusted user input (escaped or not) to shell — it's on you.

[Jcewazhere]

I love the snark behind "first you're running windows", and then later 'it feels like I should've validated my inputs'.
Windows still dominates the market share, and input validation is sadly lacking all over the place.

[AbstractObserver]

This is literally the behavior I expected... since ALWAYS

[Ariccio]

6:30 the C cast to (LPSTARTUPINFOW) is cursed. Always raises a red flag to me!

[japedr]

Just look for an article entitled "How Command Line Parameters Are Parsed". Windows command line is just crazy.

[anon_y_mousse]

I hope you see this even though it's a month late, but the execv*() functions are actually very problematic for the fact that you can elide the program name as the first argument and cause all kinds of havoc with calling an executable. Basically, if your program processes arguments in the wrong way and a third-party has called you via an execv*() function, then problems ensue.

[AK-vxdy]

Very exhaustive take on subject. Great job !

[jullien]

Muy bien amigo! Qué es tu opinion de JavaScript y Rust?

[aperturesignaturebandwidth]

What does it mean to validate an unknown/untrusted input? Is there a way to determine if some input you have wants to run an executable?

[MarekKnapek]

This behavior / issue has been with us (and properly documented) for ages. But. Somebody piled bunch of abstractions on top of it, and in meantime, forgot how the bottom layers actually worked.