35 vulnerabilities in the Squid caching proxy remain unfixed more than two years after being found and disclosed to the open source project’s maintainers, according to the person who reported them.
Squid is a caching and forwarding HTTP web proxy that is very widely used by ISPs and website operators. In February 2021, security researcher Joshua Rogers performed a security audit of Squid and said he uncovered 55 flaws in the project’s C++ source code.
Fast forward to today, and Rogers asserts only 20 of those flaws have been fixed.
The majority haven’t even been assigned CVEs, and the remaining 35 still don’t have patches or workarounds to plug the holes, we’re told.
“After two and a half years of waiting, I have decided to release the issues publicly,” Rogers wrote in a post to the Openwall security mailing list.
The Register emailed several Squid developers listed on the contact page and did not immediately receive responses to our questions. We will update this story if and when we hear from the project.
In the post, and on his website, Rogers listed 45 exploitable security issues, noting that the ten remaining are the “result of similar, but different pathways to reproduce a vulnerability.” They run the gamut from use-after-free, memory leak, cache poisoning, assertion failure, and other flaws in various components.
Rogers named the flaws and provided technical details about the vulnerabilities – including code breakdowns and PoCs – on GitHub. His website also lists 13 additional code issues that he considers to be garden variety bugs that don’t have security implications.
Rogers says he found all of the flaws in Squid-5.0.5 and performed testing in “nearly every component possible: forward proxying, reverse proxying, all protocols supports (http, https, https intercept, urn, whois, gopher, ftp), responses, requests, ‘helpers,’ DNS, ICAP, ESI, and caching. Every conceivable possible user and build configuration was used.”
Squid’s most recent version is numbered 6.3.
He also acknowledged that the Squid proxy’s maintainers – like most open source developers – are largely volunteers and may not have the support necessary to quickly fix all these problems.
“The Squid Team have been helpful and supportive during the process of reporting these issues,” Rogers conceded. “However, they are effectively understaffed, and simply do not have the resources to fix the discovered issues. Hammering them with demands to fix the issues won’t get far.”
Open source maintainer threatens to throw in the towel if companies won’t ante up
That, of course, is just the tip of a much larger iceberg: who should be responsible for maintaining and supporting open source software?
To that point, the US National Security Agency and friends on Tuesday issued a paper [PDF] on open source software in operational environments and urged vendor support – both financial and otherwise – for open source software development and maintenance.
But back to the issue at hand: with more than 2.5 million Squid instances available on the internet (according to Rogers), we’d suggest reading through the vulnerability descriptions if you are running the code.
Then, as Rogers notes, “it is up to you to reassess whether Squid is the right solution for your system.” ®