Race Condition Hackviser -

Imagine two sprinters racing down a track, but the finish line is a single door that only opens once. If they arrive at the exact same time, they both try to pass through simultaneously. The result? A jam.

In computing, a race condition occurs when two or more threads or processes attempt to modify the same shared resource (a file, a database row, or a bank balance) at the same time. The system’s output depends on the unpredictable order of execution—the "race" between the threads.

Normally, developers use "locks" (mutexes or semaphores) to prevent this. But when a lock is missing or flawed, chaos ensues. This chaos is a goldmine for a hackviser. race condition hackviser

First, we identify the SUID binary on the system.

user@hackviser:~$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
...
/opt/vuln_binary

We check the permissions and ownership:

user@hackviser:~$ ls -la /opt/vuln_binary
-rwsr-sr-x 1 root root 16784 Jan 1 12:00 /opt/vuln_binary

The s in the permissions indicates it runs with root privileges.

We run the binary to understand its logic: Imagine two sprinters racing down a track, but

user@hackviser:~$ /opt/vuln_binary
Usage: ./vuln_binary <file_to_read>

Let's test it with a file we own:

user@hackviser:~$ echo "hello" > /tmp/myfile.txt
user@hackviser:~$ /opt/vuln_binary /tmp/myfile.txt
Access Granted.
Reading file...
hello

Now, let's test it with the target flag: We check the permissions and ownership: user@hackviser:~$ ls

user@hackviser:~$ /opt/vuln_binary /root/flag.txt
Access Denied. You do not own this file.

Hypothesis: The binary checks if the user owns the file before reading it. However, if we can swap the file after the check but before the read, we can trick the program.

Once the race is won, the hackviser injects a payload (e.g., symlink to /etc/shadow, extra transaction). The payload is decoupled from the race trigger to avoid detection.