Multiple versions of the Squid web proxy cache server built with Basic Authentication features are currently vulnerable to code execution and denial-of-service (DoS) attacks triggered by the exploitation of a heap buffer overflow security flaw.
The vulnerability present in Squid 4.0.23 through 4.7 is caused by incorrect buffer management which renders vulnerable installations to “a heap overflow and possible remote code execution attack when processing HTTP Authentication credentials.”
“When checking Basic Authentication with HttpHeader::getAuth, Squid uses a global buffer to store the decoded data,” says MITRE’s description of the vulnerability. “Squid does not check that the decoded length isn’t greater than the buffer, leading to a heap-based buffer overflow with user controlled data.”
The web proxy development team patched the error with the release of Squid 4.8 on July 9.
Some unpatched servers are vulnerable to assaults
The flaw that was monitored as CVE-2019-12527 with a high severity CVSS v3.0. base score of 8.8 could be exploited by remote unauthenticated assailants, by sending a specific application to any target server to either execute arbitrary code or causing Squid to crash, triggering a DoS status.
“A remote attacker is able to exploit this vulnerability by sending a manufactured HTTP application to the target server,” explains the Trend Micro Research Team in a CVE-2019-12527 write-up.
“The successful exploitation will allow the attacker to perform arbitrary code with the server privileges, whilst a failed assault will cause the server method to end abnormally.” Luckily, according to the Squid safety team’s safety advertisement of 12 July following patching, “the problem is restricted to traffic accessing accounts of the Squid Cache Manager.
Number of unpatched Squid 4.7 servers by country
The Squid Security Advisory advises the following workarounds for uncontrollable servers:
Deny ftp:// protocol URLs being proxied and Cache Manager report access to all clients:
acl FTP proto FTP
http_access deny FTP
http_access deny manager
Or,
Build Squid with –disable-auth-basic
Still vulnerable, two further flaws have been patched
Although the vulnerability was patched early in July, from a total of 2,776,255 exposed Squid servers that were discovered using the Shodan search engine, 31,576 still run 4.7 (the final susceptible release), with only 1,957 upgraded to 4.8 patched.
We have collected a list of all susceptible Squid variants and the present amount of servers with Shodan in the table below to get an idea of how many servers could be subjected to assaults.
| Vulnerable version | Number of exposed servers |
| 4.7 | 31576 |
| 4.6 | 1314 |
| 4.5 | 108 |
| 4.4 | 7439 |
| 4.3 | 35 |
| 4.2 | 885 |
| 4.1 | 2244 |
| 4.0.25 | 4 |
| 4.0.24 | 78 |
| 4.0.23 | 294 |
| Total number of unpatched servers | 43977 |
While all of the more than 43,000 servers which have not been patched are susceptible, it can readily reach thousands depending on how many facilities with basic authentication characteristics have been installed.
The Squid 4.8 release also patched a critical flaw tracked as CVE-2019-12525, as found in Squid 3.3.9, 3.5.28, and 4.x, and Squid 2.x through 2.7.STABLE9, 3.x through 3.5.28, and CVE-2019-12529, and a medium severity through 4.7.
Remote attackers that exploit these two safety defects may crash the Squid target servers, causing a DoS status for all proxy customers.
“Squid is a high-performance proxy caching server for web clients, supporting FTP, gopher, and HTTP data objects,” says its wiki, “Squid handles all requests in a single, non-blocking, I/O-driven process over IPv4 or IPv6.”
“Squid keeps meta data and especially hot objects cached in RAM, caches DNS lookups, supports non-blocking DNS lookups, and implements negative caching of failed requests.”
