[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: Why CMD /C for .BAT scripts?
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2021-03-09 19:33:05
Message-ID: a7a66386-52da-cad0-5d2a-119748eb896d () christopherschultz ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]