Bug 14150 - squid new security issues CVE-2014-6270 and CVE-2014-714[12]
Summary: squid new security issues CVE-2014-6270 and CVE-2014-714[12]
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/615212/
Whiteboard: MGA3TOO has_procedure advisory mga3-3...
Keywords: validated_update
Depends on:
Reported: 2014-09-23 17:27 CEST by David Walser
Modified: 2014-10-07 18:12 CEST (History)
4 users (show)

See Also:
Source RPM: squid-3.3.13-1.mga4.src.rpm
Status comment:


Description David Walser 2014-09-23 17:27:52 CEST
CVEs were assigned on September 22 for a DoS issue fixed in Squid 3.4.8:

Freeze push requested for Cauldron.

The Squid 3.3 branch doesn't have a new release yet, but the same commits are present:

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:


Steps to Reproduce:
David Walser 2014-09-23 17:28:14 CEST

Whiteboard: (none) => MGA3TOO

Comment 1 David Walser 2014-10-01 16:48:46 CEST
Upstream advisory:
Comment 2 David Walser 2014-10-01 17:26:14 CEST
Patched packages uploaded for Mageia 3 and Mageia 4.


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


Updated packages in core/updates_testing:

from SRPMS:

Assignee: bugsquad => qa-bugs

Comment 3 claire robinson 2014-10-01 18:48:09 CEST
Procedure: https://bugs.mageia.org/show_bug.cgi?id=14004#c3

Whiteboard: MGA3TOO => MGA3TOO has_procedure

Comment 4 David Walser 2014-10-01 19:34:33 CEST
Up and running fine on our production Squid server at work (Mageia 4 i586).

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA4-32-OK

Comment 5 claire robinson 2014-10-02 15:42:29 CEST
Testing complete mga3 64

Whiteboard: MGA3TOO has_procedure MGA4-32-OK => MGA3TOO has_procedure mga3-64-ok MGA4-32-OK

Comment 6 Len Lawrence 2014-10-02 23:57:17 CEST
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) => tarazed25
Hardware: i586 => x86_64

Comment 7 Len Lawrence 2014-10-02 23:59:49 CEST
And, is that a valid way to run squid?  Not systemctrl?
David Walser 2014-10-03 00:00:11 CEST

Hardware: x86_64 => All

Comment 8 David Walser 2014-10-03 00:01:38 CEST
No, you should use systemctl to start the service.  Is there a PoC for the pinger issue?
Comment 9 Len Lawrence 2014-10-03 01:17:05 CEST
Haven't had the time to look yet.  Not up to speed on these things.
Comment 10 David Walser 2014-10-03 04:57:24 CEST
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.
Comment 11 Len Lawrence 2014-10-03 08:20:07 CEST
[OT]  Thanks David.  Just my impatience with so little time to spend.  Shall reduce update polling interval.
Comment 12 claire robinson 2014-10-03 14:14:28 CEST
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.
Comment 13 David Walser 2014-10-03 15:04:50 CEST
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.
Comment 14 claire robinson 2014-10-03 15:16:39 CEST
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 :)
Comment 15 Oden Eriksson 2014-10-03 16:41:52 CEST
According to the at least mga3 packages in updates_testing another patch was (silently) applied.


And it's CVE-2014-6270.

CC: (none) => oe

Comment 16 David Walser 2014-10-03 16:54:17 CEST
Thanks Oden!  I didn't see that 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

Comment 17 Len Lawrence 2014-10-03 17:00:43 CEST
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.
David Walser 2014-10-03 17:38:27 CEST

Summary: squid new security issues CVE-2014-7141 and CVE-2014-7142 => squid new security issues CVE-2014-6270 and CVE-2014-714[12]

Comment 18 Len Lawrence 2014-10-03 20:32:45 CEST

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.
Comment 19 Len Lawrence 2014-10-03 20:51:12 CEST
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
Not known
 Check the server running processes list to determine if the Squid
 service is running a "pinger" child process.
 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.


 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.
Comment 20 David Walser 2014-10-03 21:04:52 CEST
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:

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.
Comment 21 olivier charles 2014-10-04 09:24:11 CEST
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) => olchal
Whiteboard: MGA3TOO has_procedure mga3-64-ok MGA4-32-OK => MGA3TOO has_procedure mga3-64-ok MGA4-32-OK MGA4-64-OK

Comment 22 claire robinson 2014-10-06 13:21:17 CEST
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

Comment 23 claire robinson 2014-10-06 18:41:06 CEST
Validating. Advisory uploaded.

Could sysadmin please push to 3 & 4 updates


Keywords: (none) => validated_update
Whiteboard: 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-OK
CC: (none) => sysadmin-bugs

Comment 24 Mageia Robot 2014-10-07 11:23:29 CEST
An update for this issue has been pushed to Mageia Updates repository.


Resolution: (none) => FIXED

David Walser 2014-10-07 18:12:47 CEST

URL: (none) => http://lwn.net/Vulnerabilities/615212/

Note You need to log in before you can comment on or make changes to this bug.