[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #18576] -execdir vs. PATH

From: Eric Blake
Subject: [bug #18576] -execdir vs. PATH
Date: Fri, 22 Dec 2006 21:15:59 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)

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 {} +
$ 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

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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]