Why CMD /C for .BAT scripts?

["Frykenvall, Per" <pe...@cgi.com>]

Dear APR developers,

I've studied the source code of apr_proc_create and found out that given a .bat script on Windows, the command is executed using CMD.EXE /C even when using APR_PROGRAM_ENV: https://svn.apache.org/viewvc/apr/apr/trunk/threadproc/win32/proc.c?revision=1869127&view=markup#l613

I don't understand the comment before the test for .bat (and .cmd), could someone explain why the command line interpreter is used in this case?

I'm worried about command injection. I can see that measures have been taken to disallow commands like "GOOD.BAT & EVIL.BAT", but the code for that in apr_caret_escape_args seems to be dependent on a hardwired table of command line characters that need to be escaped: apr_c_is_fnchar. Can I trust that the table is up-to-date and that there are no loopholes that would allow an attacker to exploit CMD capabilities?

Would it be possible to have an option to skip this behaviour and leave the .bat file as executable to CreateProcessW?

Best regards,
Per 

Re: Why CMD /C for .BAT scripts?

[Christopher Schultz <ch...@christopherschultz.net>]

Per,

On 3/7/21 07:26, Frykenvall, Per wrote:
> Dear APR developers,
> 
> I've studied the source code of apr_proc_create and found out that given a .bat script on Windows, the command is executed using CMD.EXE /C even when using APR_PROGRAM_ENV: https://svn.apache.org/viewvc/apr/apr/trunk/threadproc/win32/proc.c?revision=1869127&view=markup#l613
> 
> I don't understand the comment before the test for .bat (and .cmd), could someone explain why the command line interpreter is used in this case?
> 
> I'm worried about command injection. I can see that measures have been taken to disallow commands like "GOOD.BAT & EVIL.BAT", but the code for that in apr_caret_escape_args seems to be dependent on a hardwired table of command line characters that need to be escaped: apr_c_is_fnchar. Can I trust that the table is up-to-date and that there are no loopholes that would allow an attacker to exploit CMD capabilities?
> 
> Would it be possible to have an option to skip this behaviour and leave the .bat file as executable to CreateProcessW?

Please be aware that it is essentially impossible to prevent 
command-injection on Windows. The Win32 API is so fundamentally broken 
as to make it nearly impossible to do.

https://docs.microsoft.com/en-gb/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

-chris

Re: Why CMD /C for .BAT scripts?

[Mladen Turk <mt...@apache.org>]

On 3/7/21 1:26 PM, Frykenvall, Per wrote:
> Dear APR developers,
> 
> I've studied the source code of apr_proc_create and found out that given a .bat script on Windows, the command is executed using CMD.EXE /C even when using APR_PROGRAM_ENV: https://svn.apache.org/viewvc/apr/apr/trunk/threadproc/win32/proc.c?revision=1869127&view=markup#l613
> 
> I don't understand the comment before the test for .bat (and .cmd), could someone explain why the command line interpreter is used in this case?
> 

Because command line interpreter is needed to execute .bat/.cmd scripts

> I'm worried about command injection. I can see that measures have been taken to disallow commands like "GOOD.BAT & EVIL.BAT", but the code for that in apr_caret_escape_args seems to be dependent on a hardwired table of command line characters that need to be escaped: apr_c_is_fnchar. Can I trust that the table is up-to-date and that there are no loopholes that would allow an attacker to exploit CMD capabilities?
> 

Well, the table is done according to MS specs. Sure there could be 
undetected errors, but the API didn't change for years


> Would it be possible to have an option to skip this behaviour and leave the .bat file as executable to CreateProcessW?
> 

Nope. CreateProcessW requires executable file.


Regards
-- 
^TM