Squid is one of the most widely-used proxy solutions for web caching and acceleration, trusted by countless organizations to manage huge volumes of HTTP, HTTPS, and FTP traffic. Like any complex software, it’s not immune to security vulnerabilities. A recent discovery, CVE-2024-37894, exposes a critical issue that attackers might use to crash Squid, simply by sending the right payload.

This post will break down the vulnerability, show you a code snippet that reflects the issue, provide useful references, and discuss how this can actually be exploited.

What is CVE-2024-37894?

CVE-2024-37894 is a vulnerability in Squid’s handling of Edge Side Includes (ESI) variables. Specifically, it relates to an Out-of-Bounds Write error—a type of memory corruption that happens when software writes data outside the boundaries of pre-allocated memory.

This bug is found when Squid tries to assign values to ESI variables. A specially crafted request hits this buggy code path, causing memory to get overwritten with unexpected content, which leads to a Denial of Service (DoS) as Squid crashes.

Technical Breakdown

When ESI processing is enabled (--enable-esi at build time), Squid assigns user-controlled variables during request processing. The problem? An insufficient bounds check means a malicious value may cause the assignment to write outside of the intended memory buffer.

Imagine you have a buffer of a certain length, but an attacker convinces Squid to write "just a bit more" than the buffer can hold. That’s the recipe for overwriting sensitive data or making the whole process crash.

Here’s a simplified example that illustrates the type of error involved

#define MAX_ESI_VARS 10

char* esi_vars[MAX_ESI_VARS];

void assign_esi_var(int idx, const char* value) {
    // No bounds checking here - dangerous!
    esi_vars[idx] = strdup(value);
}

In this pseudo code, if idx is attacker-controlled and set to 11, it writes outside the bounds of the esi_vars array. Squid’s real code has more complexity, but the vulnerability boils down to this unchecked assignment.

Real Exploit Scenario

To exploit CVE-2024-37894, an attacker does not need authentication or special privilege. They only need to send a crafted HTTP request that triggers ESI parsing with an invalid variable index or malformed data in ESI variable assignment.

A simple proof-of-concept (PoC) request might look like

GET /some-esi-page HTTP/1.1
Host: vulnerable-squid-server

<!-- ESI request attempts to use out-of-bounds variable assignment -->
<esi:assign name="attacker_var[999]" value="crashme"/>

If processed without proper checks, this input can cause Squid to overwrite data in memory it doesn't own, resulting in a segmentation fault or unpredictable behavior, effectively knocking the service offline.

What’s at Risk?

- Denial of Service: The most immediate risk is that any unauthenticated remote attacker can crash Squid, resulting in loss of service until it's restarted, whether manually or via an automated mechanism.

- Uncertain memory impact: While no direct code execution exploit is known as of now, memory corruption always carries a latent risk if attackers can further manipulate memory state.

Mitigation

- Upgrade! The best fix is to update to a patched release of Squid. Patches are already available in:
- Squid official patches
- Squid’s GitHub

- Disable ESI if you don’t use ESI processing in your deployment. This avoids triggering the vulnerable code path.

References

- Squid Security Advisory SQUID-2024:5
- NVD CVE-2024-37894 Listing
- Squid GitHub Project

Final Thoughts

CVE-2024-37894 reminds us that even mature, heavily-audited projects like Squid can sometimes overlook simple safety checks under complex features like ESI. A single missing bounds check can expose critical infrastructure to easy remote crashes.

If you run Squid, patch now. If you don’t need ESI, disable it. That’s the best way to stop opportunistic attackers from making your web cache go dark with a single HTTP request.

*Stay safe, and keep your software up-to-date!*

Disclaimer: This article is for educational purposes only. Always test vulnerabilities in controlled environments, and never attack systems without permission.

Timeline

Published on: 06/25/2024 20:15:11 UTC
Last modified on: 07/19/2024 14:15:05 UTC