CVEs were assigned on September 22 for a DoS issue fixed in Squid 3.4.8: http://openwall.com/lists/oss-security/2014/09/22/1 Freeze push requested for Cauldron. The Squid 3.3 branch doesn't have a new release yet, but the same commits are present: http://www.squid-cache.org/Versions/v3/3.3/changesets/ Upstream hasn't posted a security advisory for this yet, I would guess they will soon. Mageia 3 (Squid 3.2) is also affected. Upstream has also made commits to that branch to fix the latest issues: http://www.squid-cache.org/Versions/v3/3.2/changesets/ Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Upstream advisory: http://www.squid-cache.org/Advisories/SQUID-2014_4.txt
Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated squid packages fix security vulnerabilities: Due to incorrect bounds checking Squid pinger binary is vulnerable to denial of service or information leak attack when processing larger than normal ICMP or ICMPv6 packets (CVE-2014-7141). Due to incorrect input validation Squid pinger binary is vulnerable to denial of service or information leak attacks when processing ICMP or ICMPv6 packets (CVE-2014-7142). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7141 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7142 http://www.squid-cache.org/Advisories/SQUID-2014_4.txt ======================== Updated packages in core/updates_testing: ======================== squid-3.2.10-1.8.mga3 squid-cachemgr-3.2.10-1.8.mga3 squid-3.3.13-1.1.mga4 squid-cachemgr-3.3.13-1.1.mga4 from SRPMS: squid-3.2.10-1.8.mga3.src.rpm squid-3.3.13-1.1.mga4.src.rpm
Assignee: bugsquad => qa-bugs
Procedure: https://bugs.mageia.org/show_bug.cgi?id=14004#c3
Whiteboard: MGA3TOO => MGA3TOO has_procedure
Up and running fine on our production Squid server at work (Mageia 4 i586).
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA4-32-OK
Testing complete mga3 64
Whiteboard: MGA3TOO has_procedure MGA4-32-OK => MGA3TOO has_procedure mga3-64-ok MGA4-32-OK
Testing mageia4 x86_64 [root@vega ~]# urpmi squid Package squid-3.3.13-1.1.mga4.x86_64 is already installed [root@vega ~]# squid [root@vega ~]# ps aux | grep squid root 15873 0.0 0.0 68492 4048 ? Ss 21:49 0:00 squid squid 15876 0.1 0.0 73708 12692 ? S 21:49 0:00 (squid-1) squid 15878 0.0 0.0 4252 348 ? S 21:49 0:00 (logfile-daemon) /var/log/squid/access.log squid 15879 0.0 0.0 13200 1760 ? S 21:49 0:00 (pinger) The pinger is running. What else to check?
CC: (none) => tarazed25Hardware: i586 => x86_64
And, is that a valid way to run squid? Not systemctrl?
Hardware: x86_64 => All
No, you should use systemctl to start the service. Is there a PoC for the pinger issue?
Haven't had the time to look yet. Not up to speed on these things.
Sorry, I was away from a computer most of the day and was on a cellphone earlier so I could look it up. I don't see a PoC, just some details on the issue. I didn't know about the pinger process until this security issue came up. It processes ICMP packets, but I don't know if that's all ICMP packets sent to the machine or only certain ones. It appears that perhaps sending large ICMP packets or unusual ICMP packet types will either crash the pinger process or cause strange data to be written to /var/log/squid/cache.log. Maybe a little research on the Squid pinger process would turn up more info on how to interact with it, if needed, but probably the ping or hping commands could be used to do it. Anyway, it's probably not all that important anyway, if Squid operates normally, it should be fine. The procedure in Comment 3 is sufficent and it's pretty explicit, so you should be able to follow it. Also, just a side note, you want to be careful how you install packages for QA testing. Using urpmi is fine in this case since you really only need to test one package (squid), but urpmi isn't the best choice for updates that have multiple packages. It's better to use MageiaUpdate and cherry-pick the relevant packages while updates_testing is enabled. This should be documented on the wiki somewhere, hopefully someone can find you a reference.
[OT] Thanks David. Just my impatience with so little time to spend. Shall reduce update polling interval.
Just to clarify. Urpmi is fine, but ensure you install all the packages listed on the bug, and not just the main one. The same goes for MageiaUpdate though. I'd advise against using urpmi --searchmedia and instead enabling and disabling the Testing media as required.
If you do use urpmi in that manner, I wouldn't do it on your main machine, as it'll completely mess up orphan tracking. Also, when there are several subpackages, you often don't need to install *all* of them, just upgrade the ones you already have installed (if you have the current version of the affected package already installed). This is also easier with MageiaUpdate, as it'll only offer the ones that need to be updated as choices. With urpmi it's up to you to check your package list to see which ones those are.
The point being, it is safe to use urpmi. Just as it is safe to use MageiaUpdate. Installing all listed packages before updating them, accomplished with either method, manually installs them and negates the use of --auto-orphans to remove them. If you'd like to discuss further though let's do via another means :)
According to the at least mga3 packages in updates_testing another patch was (silently) applied. http://www.squid-cache.org/Advisories/SQUID-2014_3.txt And it's CVE-2014-6270.
CC: (none) => oe
Thanks Oden! I didn't see that advisory. Advisory: ======================== Updated squid packages fix security vulnerabilities: Due to incorrect buffer management Squid can be caused by an attacker to write outside its allocated SNMP buffer (CVE-2014-6270). Due to incorrect bounds checking Squid pinger binary is vulnerable to denial of service or information leak attack when processing larger than normal ICMP or ICMPv6 packets (CVE-2014-7141). Due to incorrect input validation Squid pinger binary is vulnerable to denial of service or information leak attacks when processing ICMP or ICMPv6 packets (CVE-2014-7142). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6270 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7141 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7142 http://www.squid-cache.org/Advisories/SQUID-2014_3.txt http://www.squid-cache.org/Advisories/SQUID-2014_4.txt
Followed Remi's prescription as crosslinked from Comment 3 and accessed the localhost cache in Firefox. Lots of links as stated. That all looks OK for 64bit. pinger next.
Summary: squid new security issues CVE-2014-7141 and CVE-2014-7142 => squid new security issues CVE-2014-6270 and CVE-2014-714[12]
http://www.squid-cache.org/Advisories/SQUID-2014_3.txt According to this the SNMP vulnerability does not present itself if squid.conf does not enable any snmp ports. This is the case for the default config file in the current update.
pinger DOS problem This is an edited extract from the SQUID-2014_4.txt advisory: All Squid built with --disable-icmp are not vulnerable to these problems. Not known Check the server running processes list to determine if the Squid service is running a "pinger" child process. Yes All unpatched Squid-2.x and Squid-3.x versions up to and including 3.4.7 running the pinger process are vulnerable to these problems. Yes __________________________________________________________________ Workaround: Configuring the firewall controlling access to Squid service such that only ICMP ECHO packets are allowed delivery to the Squid pinger process will limit the denial of service vulnerability. Beyond my competence.
We have --enable-icmp (you can see it in the SPEC file) and you can obviously see the pinger process in the process list as you mentioned. As far as the workaround statement, it's not complicated. All it's saying is if you limit yourself to only accepting ICMP Echo (Requests and Replies), aka pings (and ping replies), it should be OK. If you allow your machine to accept other ICMP packet types, you're exposed to the vulnerability. See this for other types: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol I think hping lets you send arbitrary types. Anyway, we're probably getting more into the weeds than we need to. If normal operation works fine, you can OK this.
Testing in Mageia4-64, H/W Installed : - squid-3.3.13-1.1.mga4.x86_64 - squid-cachemgr-3.3.13-1.1.mga4.x86_64 Used procedure as in Comment 3. Set up Firefox 24.8.0 as advised and started httpd and squid services # systemctl -l status squid squid.service - LSB: Starts the squid daemon Loaded: loaded (/etc/rc.d/init.d/squid) Active: active (running) since sam. 2014-10-04 09:07:18 CEST; 28s ago Process: 28177 ExecStart=/etc/rc.d/init.d/squid start (code=exited, status=0/SUCCESS) Main PID: 28196 (squid) CGroup: /system.slice/squid.service ââ28193 squid ââ28196 (squid-1) ââ28197 (logfile-daemon) /var/log/squid/access.log ââ28198 (pinger) Restarted Firefox Browsed to https://www.mageia.org, then to http://localhost/cgi-bin/cachemgr.cgi which opened a page titled : <<Cache Manager menu for localhost:>> which itself contained around fifty links, some of them marked "hidden" Followed several links, all contained data. /var/log/squid/access.log written on disk. Nothing to report, everything OK according to procedure
CC: (none) => olchalWhiteboard: MGA3TOO has_procedure mga3-64-ok MGA4-32-OK => MGA3TOO has_procedure mga3-64-ok MGA4-32-OK MGA4-64-OK
Testing complete mga3 32
Whiteboard: MGA3TOO has_procedure mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK
Validating. Advisory uploaded. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0396.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/615212/