Microsoft Windows Unsafe Handling Practices

`Hi @ll,  
  
This multi-part post can be read even without a MIME-compliant program!  
  
Back in 2014, I reported a vulnerability in CreateProcess()'s handling of  
*.cmd and *.bat files that Microsoft fixed with MS14-019 alias MSKB 2922229  
and assigned CVE-2014-0315: command lines with a batch script as first token  
led to the execution of a (rogue) cmd.exe from the CWD (or the search path).  
  
<https://blogs.technet.microsoft.com/srd/2014/04/08/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/>  
provides some details about the vulnerabilities attack vector.  
  
With that in mind, read the documentation of the command processors START  
builtin command <https://msdn.microsoft.com/en-us/library/cc770297.aspx> or  
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start>  
  
| * When you run a command that contains the string "CMD" as the first token  
| without an extension or path qualifier, "CMD" is replaced with the value  
| of the COMSPEC variable. This prevents users from picking up cmd from  
| the current directory.  
  
This statement is but WRONG: START CMD ... picks a rogue cmd.exe from the CWD!  
  
Demonstration/Proof of concept #1  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
On a default installation of Windows XP or any newer version, start the command  
processor CMD.EXE and run the following commands:  
  
CHDIR /D "%TMP%"  
COPY "%SystemRoot%\Write.exe" Cmd.exe  
SET COMSPEC=  
SET PATH=  
START CMD /C PAUSE  
  
  
This weakness is well-known and well-documented: see  
<https://cwe.mitre.org/data/definitions/73.html>,  
<https://cwe.mitre.org/data/definitions/426.html> and  
<https://cwe.mitre.org/data/definitions/427.html>  
  
For some of the well-known attacks see  
<https://capec.mitre.org/data/definitions/13.html> and  
<https://capec.mitre.org/data/definitions/471.html>  
  
  
Now continue with the documentation of the command processors FOR builtin  
command <https://msdn.microsoft.com/en-us/library/cc754900.aspx> or  
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/for>  
  
| * Parsing output:  
| You can use the for /f command to parse the output of a command by placing  
| a back-quoted <command> between the parentheses.  
  
Back-quoted is only correct with FOR /F "UseBackQ" %<var> IN (´<command>´) DO ...  
Without "UseBackQ" the command needs to be placed in single quotes!  
  
  
| It is treated as a command line, which is passed to a child Cmd.exe.  
  
That too is wrong: if COMSPEC is set, its value is used as file/pathname of the  
child process; Cmd.exe is used only if COMSPEC is not set!  
  
Demonstration/Proof of concept #2  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
On a default installation of Windows XP or any newer version, start the command  
processor CMD.EXE and run the following commands:  
  
SET COMSPEC=%SystemRoot%\System32\Reg.exe  
FOR /F %? IN ('SET') DO @ECHO %?  
  
Evaluating COMSPEC inside the command processor or executing the hard-coded  
file Cmd.exe is both clumsy and unsafe!  
The command processor can and should determine its own module name instead.  
  
  
For a third bug and vulnerability see the following undocumented and outright  
BRAINDEAD behaviour.  
  
Demonstration/Proof of concept #3  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
On a default installation of Windows XP or any newer version, start the command  
processor CMD.EXE and run the following commands:  
  
SET COMSPEC=%SystemRoot%\System32\Reg.exe  
ASSOC | CALL  
ECHO | FTYPE  
SET | More.com  
...  
  
  
Why does the command processor execute the EXTERNAL command specified in the  
environment variable COMSPEC to run its builtin INTERNAL commands?  
  
  
stay tuned, and far away from such blunders  
Stefan Kanthak  
  
PS: for more quirks see <https://skanthak.homepage.t-online.de/quirks.html>  
  
  
  
`