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