Bug 83509 - (CVE-2005-1519) VUL-0: CVE-2005-1519: squid bugs
VUL-0: CVE-2005-1519: squid bugs
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other All
: P5 - None : Normal
: ---
Assigned To: Security Team bot
Security Team bot
CVE-2005-1519: CVSS v2 Base Score: 6....
Depends on: 90338
  Show dependency treegraph
Reported: 2005-05-12 14:54 UTC by Ludwig Nussel
Modified: 2021-11-04 16:09 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

all relevant lines from /var/log/squid/access.log (212 bytes, text/plain)
2005-06-29 09:34 UTC, Heiko Rommel
network traffic in libpcap format (just load into ethereal and "follow tcpstream") (5.47 KB, application/octet-stream)
2005-06-29 09:35 UTC, Heiko Rommel
squid startup messages from /var/log/messages (3.15 KB, text/plain)
2005-06-29 09:35 UTC, Heiko Rommel

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2005-05-12 14:54:38 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


Today a new security issue on squid-2.5.STABLE9 was reported:


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.


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:


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.


Configure your web server to restrict which users may use the
cachemgr.cgi CGI program.


I didn't saw this one:


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

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
Comment 1 Klaus Singvogel 2005-05-12 15:05:19 UTC
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. 
Comment 2 Klaus Singvogel 2005-05-12 15:05:49 UTC
As argued before: LATER.  
Comment 3 Thomas Biege 2005-06-23 09:24:53 UTC
Comment 4 Thomas Biege 2005-06-23 09:39:56 UTC
update in the queue
Comment 5 Heiko Rommel 2005-06-29 09:33:12 UTC
Either this fix or the fix to Bug #90338 breaks squid on sles9-s390x (and only

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:


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.
Comment 6 Heiko Rommel 2005-06-29 09:34:23 UTC
Created attachment 40344 [details]
all relevant lines from /var/log/squid/access.log
Comment 7 Heiko Rommel 2005-06-29 09:35:16 UTC
Created attachment 40346 [details]
network traffic in libpcap format (just load into ethereal and "follow tcpstream")
Comment 8 Heiko Rommel 2005-06-29 09:35:47 UTC
Created attachment 40347 [details]
squid startup messages from /var/log/messages
Comment 9 Ludwig Nussel 2005-06-29 09:39:53 UTC
reassign to maintainer  
Comment 10 Klaus Singvogel 2005-06-29 17:57:49 UTC
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. 
Comment 11 Klaus Singvogel 2005-06-29 18:00:34 UTC
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. 
Comment 12 Klaus Singvogel 2005-06-29 19:15:04 UTC
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. 
Comment 13 Thomas Biege 2005-07-02 07:56:17 UTC
packages approved
Comment 14 Ludwig Nussel 2005-07-11 16:18:16 UTC
the dns query issue is CAN-2005-1519 
Comment 15 Thomas Biege 2009-10-13 21:23:35 UTC
CVE-2005-1519: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:N/I:P/A:P)