Is this the same Squid that is the basis of many comercial web filters? A few years ago I evaluated web filtering hardware and most of the inline solutions on the market were based on Squid.
What do modern server admins use for filtered HTTP/S egress from servers? E.g., if the app has a need to fetch HTTP/S sites for the user but needs to do so in a safe way?
I didn’t review all of the bugs, but the ones I looked at are unlikely to be leveraged: FTP, Gopher, ESI, Digest Authentication…. These things are rare in the wild (Except perhaps FTP but I believe squid must be configured to allow FTP proxying anyway).
That is probably why they have not been fixed. The best solution is to drop support for these technologies from squid altogether, rather than someone waste precious time fixing them.
If you only look at the esoteric issues, then yes, it would seem that they're unlikely to be leveraged.
However, from the top 5:
Chunked Encoding Stack Overflow
X-Forwarded-For Stack Overflow
Cache Poisoning by Large Stored Response Headers (With Bonus XSS)
all pertain to issues affecting practically every single Squid instance.
Except perhaps FTP but I believe squid must be configured to allow FTP proxying anyway
This is specifically mentioned, for example https://megamansec.github.io/Squid-Security-Audit/ftp-assert...:
A reproducer is given base64-encoded. (Note: This does NOT require Squid to even be enabled to proxy FTP links, and even with the configurationacl ftp proto FTPhttp_access deny ftpthis crash will occur).
> The best solution is to drop support for these technologies from squid altogether, rather than someone waste precious time fixing them.
This is exactly how organizations and larger software distributions get stuck on outdated versions of software packages. They are using some feature in the software to glue things together or something, the package drops that support, and they get stuck because they can't make a massive software upgrade happen quickly, or some aspect of that interface is outside their control.
I have seen this so much that its not even something that surprises me. I am not even surprised about the other side of the argument that seems to assume that you can just burn a ton of code or even a ton of hardware just because its no longer the style in vogue these days. And then these people wonder why companies that make 50 year guarantees of software compatibility like IBM are so popular.
12 comments
[ 3.2 ms ] story [ 40.3 ms ] threadThat is probably why they have not been fixed. The best solution is to drop support for these technologies from squid altogether, rather than someone waste precious time fixing them.
However, from the top 5:
all pertain to issues affecting practically every single Squid instance.Except perhaps FTP but I believe squid must be configured to allow FTP proxying anyway
This is specifically mentioned, for example https://megamansec.github.io/Squid-Security-Audit/ftp-assert...: A reproducer is given base64-encoded. (Note: This does NOT require Squid to even be enabled to proxy FTP links, and even with the configuration acl ftp proto FTP http_access deny ftp this crash will occur).
This is exactly how organizations and larger software distributions get stuck on outdated versions of software packages. They are using some feature in the software to glue things together or something, the package drops that support, and they get stuck because they can't make a massive software upgrade happen quickly, or some aspect of that interface is outside their control.
I have seen this so much that its not even something that surprises me. I am not even surprised about the other side of the argument that seems to assume that you can just burn a ton of code or even a ton of hardware just because its no longer the style in vogue these days. And then these people wonder why companies that make 50 year guarantees of software compatibility like IBM are so popular.