Previous: O_NOFOLLOW, Up: Changing the Current Working Directory


11.2.2.2 Systems without O_NOFOLLOW

The strategy for preventing this type of problem on systems that lack support for the O_NOFOLLOW flag is more complex. Each time find changes directory, it examines the directory it is about to move to, issues the chdir() system call, and then checks that it has ended up in the subdirectory it expected. If all is as expected, processing continues as normal. However, there are two main reasons why the directory might change: the use of an automounter and the someone removing the old directory and replacing it with something else while find is trying to descend into it.

Where a filesystem “automounter” is in use it can be the case that the use of the chdir() system call can itself cause a new filesystem to be mounted at that point. On systems that do not support O_NOFOLLOW, this will cause find's security check to fail.

However, this does not normally represent a security problem, since the automounter configuration is normally set up by the system administrator. Therefore, if the chdir() sanity check fails, find will make one more attempt1. If that succeeds, execution carries on as normal. This is the usual case for automounters.

Where an attacker is trying to exploit a race condition, the problem may not have gone away on the second attempt. If this is the case, find will issue a warning message and then ignore that subdirectory. When this happens, actions such as ‘-exec’ or ‘-print’ may already have taken place for the problematic subdirectory. This is because find applies tests and actions to directories before searching within them (unless ‘-depth’ was specified).

Because of the nature of the directory-change operation and security check, in the worst case the only things that find would have done with the directory are to move into it and back out to the original parent. No operations would have been performed within that directory.


Footnotes

[1] This may not be the case for the fts-based executable