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