[bug #18576] -execdir vs. PATH

[Eric Blake]

Follow-up Comment #2, bug #18576 (project findutils):

One additional reduction in false positives is still possible.  Currently,
-execdir gripes even if the PATH search would not have found the
directory-relative program:

$ PATH=/usr/bin find -execdir echo {} +
./a
$ PATH=/usr/bin: find -execdir echo {} +
find: The current directory is included in the PATH environment variable,
which is insecure in combination with the -execdir action of find.  Please
remove the current directory from your $PATH (that is, remove "." or leading
or trailing colons)

But it should be possible to examine the PATH, and realize that since
/usr/bin/echo exists, it will always be chosen rather than ./echo.  A
reformulation of this is that from a security point of view, /bin:. is a more
secure PATH than .:/bin (both have risk, but by listing . last, you have
reduced the risk; no matter what directory you are in, you will still get
/bin/echo).

So, maybe the rule should be:
If the first argument after -execdir contains /, proceed without warning.
Otherwise, start visiting components in PATH, looking for an executable file
that matches the first argument after -execdir.  If the command is found
while encountering only absolute path components, proceed without warning. 
But if any path component is found that is relative, and the program has not
yet been discovered, then fail due to the security risk.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?18576>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/