What is wrong with access()? [duplicate]

Question

Possible Duplicate:
access() Security Hole

I quote from man page access(2):

Warning: Using access() to check if a user is authorized to, for example, open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. For this reason, the use of this system call should be avoided.

What does this mean, and in what situation would it be a concern?

Answer 1

It is a classic "Time of check to time of use" race condition.

Answer 2

This is a security concern only for Set-user-ID and set-group-ID applications. For applications running as the user itself there is no threat, because the operation in question would be rejected by the operating system anyway.

Consider this scenario: you have a UNIX program running as root via set-user-id. The program uses access to check file permissions of another user, and then runs the file as root, but only if the permission check has been successful. Let's say the program is called securerun, and you run it as follows:

securerun myfile

An attacker can make a program that exploits this security hole to run, using this algorithm:

• Write a file xyz of which the user has executing permissions
• Start two threads, A and B
• Thread A waits a few milliseconds, and executes cp norunning xyz to replace xyz with a file that the attacker wants to run, but has no run permissions to do so
• Thread B calls securerun xyz

If the attacker gets lucky by getting his timing right, your securerun would check the execute permissions on the old xyz, but it would run the new xyz, a copy of norunning that the hacker wasn't supposed to run. Since there is a short time window between the check and the execution, the attacker is bound to get lucky at some point, if he tries his strategy many times in a loop.