BatBadBut: You can't securely execute commands on Windows • Hacker News Board

Re: BatBadBut: You can't securely execute commands on Windows

#41

Post by MarkSweep » Wed, Apr 10, 2024, 10:54 PM UTC

theamk wrote: post #34

trelliscoded wrote: post #31

Earlier quoted context omitted.

Disabling script signing on dev machines and requiring signatures on production scripts sounds like perfectly reasonable behavior to me. I know a lot of people are scared of pki but it’s way easier than people think. Signing things is a one liner, I keep certs on a portable HSM and it’s really low friction.

Unless you suddenly get sick and your HSM is unavailable? Unless you get a 2nd person on the team (working remotely), and they want to be able to sign scripts as well? Unless you get some sort of automated CI/CD system?

You can still turn off the script signing requirement without running a script (right?). Presumably this will be logged to the Windows Event Log, so there should be a mechanism that watches logs for this and alerts someone to investigate.

Re: BatBadBut: You can't securely execute commands on Windows

#42

Post by MatejKafka » Thu, Apr 11, 2024, 11:36 AM UTC

ptx wrote: post #24

This is a weird coincidence – I ran into this exact problem two days ago, the day before the post was published. I was just trying to write a simple batch script that accepted filenames as arguments and was surprised to find that there is no safe way to do so, as they're always passed through shell expansion, so if you have a filename like "foo %PATH% bar.txt" (which is allowed) the script will receive it with the PA…

From a quick read through the source code, .NET seems to use CommandLineToArgv, so the behavior is the same. Additionally, the behavior of internal parsing in the CRT and CommandLineToArgv is very similar, and from my experience, it's easy to escape arguments in a way where both interpret them the same way (it's dumb that there's a difference between the two in the first place, but it only really comes up with manual input).

In practice, with the exception of `cmd.exe`, which is an old beast that cannot be redeemed due to backwards compatibility, there is a consistent way to round-trip argv to more-or-less all programs one encounters in the wild. It's not a guarantee and I'm sure you could find a program which does something weird, but you could find the same in the POSIX world. In both cases, we can probably agree that it's the mistake of the program that it's parsing arguments in a non-standard way.

Re: BatBadBut: You can't securely execute commands on Windows

#43

Post by MarkSweep » Fri, Apr 12, 2024, 2:36 AM UTC

MarkSweep wrote: post #37

kazinator wrote: post #12

> And unfortunately, the cmd.exe has different escaping rules compared to the usual escaping mechanism. This "usual escaping mechanism" is a bit of a weasel word. Windows passes a single null-terminated character string to a process. Every application run-time must parse that into arguments itself. I think what "usual escaping mechanism" refers to is the algorithm implemented in the Microsoft Visual C Run Time which…

The “usual escaping mechanism” may also refer to CommandLineToArgvW, a Windows API function that implements this. I think it is a pretty common way to implement the parsing side, though I’m not sure if the Visual C runtime does something different. https://learn.microsoft.com/en-us/windows/win32/api/shellapi...

Some more details on this, apparent CommandLineToArgvW implements a slightly different parsing algorithm that the Visual C++ runtime:

https://learn.microsoft.com/en-us/cpp/cpp/main-function-comm...

Also, here is another implementation of this algorithm in C#, used in .NET:

https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...