Open szmate1618 opened 2 years ago
Interesting. I agree it's a bug, though I'm not thinking of a way it would harm
a program other than a program going out of its way to be harmed. With or
without this bug, a program that doesn't trust its PATH needs to replace that
PATH with a known-good value. (perlsec documents this.) Even if one misses
that precaution, a normal IPC::Run program won't attempt to execute [undef]
and
will remain unaffected.
The minimal reproducible example I found is the following (in Powershell):
This will start mspaint.exe, but it could be any executable. The .exe extension can be omitted, as
PATHEXT
is also taken into account. I believe this is a bug and a potential security issue, as I don't expectrun
to run anything else than what I pass as an argument. Of course, normallyPATH
should only contain directories, not executables, but I found it to be fairly easy to accidentally copy-paste a full path to an executable into it. That's how I discovered this behavior.The root cause of the issue seems to be that passing
\@SomeUndefinedArray
torun
passes an empty string to_search_path
which empty string then will be concatenated to every path found inPATH
and executed if it points to an executable. Unfortunately every executable path onPATH
+ an empty string is guaranteed to point to an executable path.The issue seems to be only present on Windows. I believe the reason for this is the different behavior of
File::Spec->catfile()
between different OSs: Windows:WSL terminal:
for whatever reason Mac seems to do this:
Note the missing trailing separator on Windows.