Don't run proc_open_cmd.phpt in parallel with other tests

This test puts a fake cmd.exe in the CWD and removes it only after the
test has finished. We need to avoid that other tests are

Don't run proc_open_cmd.phpt in parallel with other tests

This test puts a fake cmd.exe in the CWD and removes it only after the
test has finished. We need to avoid that other tests are running while
that fake cmd.exe is there, because they may use it instead of the
proper cmd.exe.

We also unlink the fake cmd.exe as soon as possible, regardless of the
test result.

Fixes GH-17098.
Closes GH-17090.

show more ...

Harden proc_open() against cmd.exe hijacking

As is, whenever `proc_open()` needs to invoke the shell, cmd.exe is
looked up in the usual executable search path. That implies that any

Harden proc_open() against cmd.exe hijacking

As is, whenever `proc_open()` needs to invoke the shell, cmd.exe is
looked up in the usual executable search path. That implies that any
cmd.exe which is placed in the current working directory (which is not
necessarily what is reported by `getcwd()` for ZTS builds), will be
used. This is a known attack vector, and Microsoft recommends to
always use the fully qualified path to cmd.exe.

To prevent any cmd.exe in the current working directory to be used, but
to still allow users to use a drop in replacement for cmd.exe, we
search only the `PATH` for cmd.exe (and pass the fully qualified path
to `CreateProcessW`), instead of relying on automatic executable search
by passing the base name only.

To be able to easily test this, we provide a minimalist C file which
will be build as test_helper, and used by the new test case.

[1] <https://msrc.microsoft.com/blog/2014/04/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/>

Closes GH-17043.

show more ...