Reportedly SquidGuard is prone to a remote NULL URL character unauthorized access vulnerability. This issue is due to a failure of the application to properly filter out invalid URIs. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. See http://www.securityfocus.com/bid/9919/discussion/ Securityfocus gives the following: --- cut here --- Reportedly SquidGaurd is prone to a remote NULL URL character unauthorized access vulnerability. This issue is due to a failure of the application to properly filter out invalid URIs. Successful exploitation of this issue may allow a remote attacker to bypass access controls resulting in unauthorized access to attacker-specified resources. This may allow the attacker to gain unauthorized access to sensitive resources. Although it has not been confirmed, this issue may be related to the issue defined in BID 9778. --- cut here--- BID 9778 is also in bugzilla, Bug 45273. Unfortunately it seems that there is no newer version of squidguard. :-(
I'll take care of this one.
Andrea : please set the bug to ASSIGNED when you confirm that here is a vulnerability and that it affects Gentoo. -K
Still no action from the squidguard folks on this. Looking around, it appears as though there is a proof-of-concept exploit, as discussed on securityfocus: http://www.securityfocus.com/bid/9919/exploit/ If someone out there is a squid user and could test this, we would certainly appreciate it. Squidguard itself hasn't been upgraded (according to their site) since 2001. I'm inclined to call this an abandoned project and yank it/hard mask it in portage. Unless someone can test the above exploit and confirm that it is *not* vulnerable, this will likely be our course of action.
I am unable to confirm this bug. I run SquidGuard on two proxy servers, both are based on Debian machines though, and I have run several attempts of the proof-of-concept URL through wget, Mozilla, lynx and by manual telnet to port 8080 and cannot force squidguard to download a page it wasn't supposed to. There is a note in the changelog for the Debian package : "Allow room for null terminator when loading diffs to .db files" (referencing bug 139238) which might be relevant.
I'm almost certain this is in fact a Squid problem, not SquidGuard. Please see : http://www.securityfocus.com/bid/9778/info/ The machines I tested with use Squid 2.5.2 and 2.5.4. The 2.5 series is listed as not vulnerable to the problem noted in the above URL.
Bah, it says 2.5.5 isn't vulnerable, but I can't force my installs of 2.5.2 or 2.5.4 to exhibit this behaviour. I'll note that the 2.5.2 install is being routed via another 2.5.4 install, so this might have been resolved in the Debian package since between 2.5.2-1 and 2.5.4-5, although I don't see anything in the changelog about it.
ok, I'm inclined to close this bug as invalid then. I'll leave it open for another 24h to allow further comment and then either myself or another member of the security team is welcome to close it. Tarragon -- thank you very much for your help in testing this.
Yes, it seems that the vulnerable code is taken from squid and not squidguard. (squid/lib/rfc1738.c) I'm closing it then. thx everybody for the help.
