Bugzilla – Bug 83509
VUL-0: CVE-2005-1519: squid bugs
Last modified: 2021-11-04 16:09:55 UTC
We received the following report via vendor-sec. The issue is public. Just for completeness. The bugs don't sound severe to me. Do you want to fix them or better wait for something bigger? Date: Wed, 11 May 2005 17:20:57 +0200 From: Klaus Singvogel <klaus@lst.de> To: vendor-sec@lst.de Subject: [vendor-sec] new squid flaw Hello --------------------------------------------------------------------------- Today a new security issue on squid-2.5.STABLE9 was reported: http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE9-dns_query Synopsis: Malicious users may spoof DNS lookups if the DNS client UDP port (random, assigned by OS at startup) is unfiltered and your network is not protected from IP spoofing. Patch: http://www.squid-cache.org/Versions/v2/2.5/bugs/squid-2.5.STABLE9-dns_query-4.patch Workaround: Firewall your Squid server to not allow spoofed DNS responses to reach the server. --------------------------------------------------------------------------- An older one, which I'm not aware of is this one: http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE9-cachemgr_conf Synopsis: This patch adds access controls to the cachemgr.cgi script, preventing it from being abused to reach other servers than allowed in a local configuration file. Patch: http://www.squid-cache.org/Versions/v2/2.5/bugs/squid-2.5.STABLE9-cachemgr_conf.patch Workaround: Configure your web server to restrict which users may use the cachemgr.cgi CGI program. --------------------------------------------------------------------------- I didn't saw this one: CAN-2005-1345 Problem description: Squid 2.5.STABLE9 and earlier does not trigger a fatal error when it identifies missing or invalid ACLs in the http_access configuration, which could lead to less restrictive ACLs than intended by the administrator. reported on lwn.net by Trustix today. no more information known by me. -- Klaus Singvogel GnuPG-Key-ID: 1024R/5068792D 1994-06-27 _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Thanks. :-) I also think that these problems are of minor severity. I'm currently still working on the unace issue (as expected: takes a bit longer to dig in). So, if there is no real need to build an update (e.g. from L3), then we should wait till next major problem and include it then.
As argued before: LATER.
SM-Tracker-1628
update in the queue
Either this fix or the fix to Bug #90338 breaks squid on sles9-s390x (and only that!). Looks like squid runs into some weired DNS resolver problems. The setup I used: - use s390zvc24 as proxy for all protocols supported by firefox - access http://www.novell.com/linux/ After waiting for some seconds you get: --------------------------------- The requested URL could not be retrieved While trying to retrieve the URL: http://www.novell.com/linux/ The following error was encountered: Unable to determine IP address from host name for www.novell.com The dnsserver returned: Timeout This means that: The cache was not able to resolve the hostname presented in the URL. Check if the address is correct. Your cache administrator is webmaster. Generated Wed, 29 Jun 2005 09:22:00 GMT by s390zvc24.suse.de (squid/2.5.STABLE5) ------------------------------- I tried both the GA version of squid for sles9-s390x and the last maintenance update (patch 10032 - md5sum fce96418deb2ca446635af24ff7e4a01). These work! Logs/attachments follow.
Created attachment 40344 [details] all relevant lines from /var/log/squid/access.log
Created attachment 40346 [details] network traffic in libpcap format (just load into ethereal and "follow tcpstream")
Created attachment 40347 [details] squid startup messages from /var/log/messages
reassign to maintainer
found the problem (a wrong pointer declaration in upstream patch, might break on _any_ 64bit architecture) and fixed it. submitted new packages. reassigning back to security-team for further processing.
note: this affects only: 9.1 (SLES9), 9.2 and 9.3 there is another (upstream) patch for the older squid versions, where this declaration is correct. therefore SLES8, 8.2, 9.0 are not affected.
I realized that this problem is already fixed (different) upstream and a change of 9.3 is not necessary. So, it re-work was only necessary for: 9.1 (SLES9) and 9.2. I removed 9.3 submission.
packages approved
the dns query issue is CAN-2005-1519
CVE-2005-1519: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:N/I:P/A:P)