This is a security issue only for Set-user-ID and set-group-ID applications. For applications running as the user himself, there is no threat, since this operation will be rejected by the operating system in any case.
Consider this scenario: you have a UNIX program running as root through set-user-id. The program uses access to check access rights to the files of another user, and then runs the file as root , but only if the permission check was successful. Let's say the program is called securerun , and you run it like this:
securerun myfile
An attacker could create a program that uses this security hole to run using this algorithm:
- Write the
xyz file in which the user executes permissions - Run two threads,
A and B - Thread
A waits a few milliseconds and performs cp norunning xyz to replace xyz with the file that the attacker wants to run, but does not have permission to run for this - Topic
B invokes securerun xyz
If the attacker is lucky in returning the correct time to it, your securerun will check the execution permissions for the old xyz , but it will start the new xyz , a copy of norunning that the hacker wasn "I have to run. Since there is a short time window between the check and the execution, the attacker in some point will succeed if he repeatedly tries to implement his strategy in a cycle.
source share