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?
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.
It is a classic "Time of check to time of use" race condition.
Typical erroneous code:
- Use
access
to check whether to read file on user's behalf, in a program running with elevated privileges
- Short gap here
- Open file
During the "short gap", the user might be able to manipulate the file system, for example:
ln -f secret_file.txt non_secret_file.txt
Then open
will open the secret file for reading, even though it would have failed the access
check had the link been in place at the time the check was done.