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
