Critical Bug Could Open 50K+ Tinyproxy Servers to DoS, RCE

Around 50,000 instances of an open source proxy server used for small networks are exposed to denial-of-service (DoS) attacks and even potentially remote code execution (RCE), via a flaw that can be exploited by an HTTP request.

A use-after-free flaw tracked as CVE-2023-49606 is present in Tinyproxy versions 1.11.1 and 1.10.0; it allows attackers to send a simple, specially crafted HTTP Connection header to trigger memory corruption that can cause DoS, according to a recent advisory by threat-hunting platform provider Censys. Further, a more complex attack also can allow for RCE attacks. The flaw garners a critical rating of 9.8 out of 10 on the CVSS vulnerability-severity scale.

Tinyproxy is a lightweight, open source HTTP/S proxy for Unix-like operating systems that's designed for use in small networks, so most of its users are likely to be small businesses, public Wi-Fi providers, and home users, according to Censys. However, it's also used by enterprises for testing or development, so attackers can compromise these instances of the server as well.

"Despite its design for smaller networks, compromising a proxy server can have serious consequences such as data breaches and service disruptions," according to the advisory.

Though there is as yet no known active exploitation of the flaw, an Internet search conducted by Censys showed that as of May 3, there are more than 90,000 hosts exposing a Tinyproxy service. Of those, more than 57% are potentially vulnerable to the exploit, according to the advisory.

The network with the greatest concentration of Tinyproxy servers is AMAZON-02 from Amazon Web Services, "which makes sense given that this software is likely used by smaller, individual users," according to Censys. 

Public Exploit Available — but Does It Work?

Cisco Talos on May 1 published proof-of-concept exploit for the flaw, saying that it demonstrates how a simple HTTP request can trigger CVE-2023-49606. But a post on GitHub by the maintainer of the Tinyproxy project — who goes by the online name "rofl0r" — called Cisco Talos' description of the flaw and how it's exploited "useless details" that don't focus on the actual bug or paint a true depiction of how to exploit it.

The maintainer goes on in the post to describe the flaw, deemed as "nasty," and includes a link to an update that Tinyproxy's maintainer said fixes the vulnerability.

Cisco Talos did not immediately respond to request for comment Wednesday on the claims made by rofl0r that refute its researchers' assessment of the flaw and its exploit.

Breaking Down the Tinyproxy Bug

The flaw resides in code to remove the "connection" and "proxy-connection" headers from the list of headers received in the src/reqs.c, remove_connection_headers() request in Tinyproxy, according to rofl0r's GitHub post.

The affected code was written in 2002 and was never updated, according to rofl0f, and it triggers the following chain of events: The value of either "connection" or "proxy-connection" is retrieved from the key-value (KV) store, it is split up in pieces using a number of potential delimiters, and each piece is removed from the KV store.

"The bug is that if one of those pieces is either 'connection' or 'proxy-connection' (case-insensitive) and the same as the key used earlier to retrieve the value," the maintainer explained. "It will be deleted (freed) from the [KV] store, but the code continues accessing the value pointer it retrieved earlier."

The bug "certainly allows" a DoS attack on the server if it "is either using musl libc 1.2+ - whose hardened memory allocator automatically detects UAF, or built with an address sanitizer," according to the post. It also "can indeed" potentially lead to RCE.

Exposure & Mitigation for CVE-2023-49606

While Cisco Talos claims that an attacker can make a simple unauthenticated HTTP request to trigger the vulnerability, rofl0r refuted that claim, noting that the code is "only triggered after access list checks and authentication have succeeded."

This means that if a Tinyproxy administrator uses basic authentication with a reasonably secure password, they are protected against compromise. Additionally, if the proxy is available only on a trusted private network, such as inside a corporate environment, it can't be exploited by external attackers, according to rofl0r.

In addition to installing the update provided on GitHub, Tinyproxy administrators also can avoid potential compromise by ensuring that a Tinyproxy service is not exposed to the public Internet, particularly if it's in use in a development or testing environment, according to Cisco Talos.