Debian has issued an advisory today (August 27): https://www.debian.org/security/2020/dsa-4751 Upstream has issued advisories for these on August 23: https://github.com/squid-cache/squid/security/advisories/GHSA-c7p8-xqhm-49wv https://github.com/squid-cache/squid/security/advisories/GHSA-vvj7-xjgq-g2jg https://github.com/squid-cache/squid/security/advisories/GHSA-3365-q9qx-f98m The issues are fixed upstream in 4.13. Updated to 4.13 in SVN. Letting Bruno look before pushing it. Side note to Bruno, I've built a couple mga7 systems recently and the line in the init script that says " $SQUID -z -F >> /var/log/squid/squid.out 2>&1" in start() fails on a new installation. Not sure if there's something that can be done about that.
$SQUID -z -F is called to create the spool directory when it's detected as empty. The cache dir is taken from squid.conf as cache_dir param. squid runs that as the squid user (and group) so if it fails you should check whether the default dir is different, who owns it, who can write in it to create all the subdirs needed by squid. our rpm package seems to hard code /var/spool/squid in the preinstall scriptlet. Maybe if you changed it, that's a reason...
Status: NEW => ASSIGNED
I haven't changed anything on a fresh installation. /var/spool/squid is 755 squid:squid and is created and owned by the package and no cache_dir parameter is set by default. squid.conf.documented says the following: #Default: # No disk cache. Store cache ojects only in memory. So there's no need for it to create or initialize anything on startup, but there's no reason for it to fail on that either. I don't think any of this is new except for the failure.
It definitely fails to start at boot. Maybe it is trying to start before /var is mounted. If it was a systemd unit I guess it'd need After=var.mount, but I'm not sure how to do that with a SysV init script.
Can Squid initscript be converted integraly to a systemd-unit .service file?
Seems there is a systemd-unit .service file here: https://github.com/squid-cache/squid/blob/master/tools/systemd/squid.service
Also see this on gentoo forum: [Unit] Description=Squid web caching proxy After=syslog.target network.target network-online.target nss-lookup.target [Service] Environment="SQUID_CONF=/etc/squid/squid.conf" Environment="SQUID_OPTS=-Y" LimitNOFILE=16384 ExecStartPre=/usr/sbin/squid -N -z -f ${SQUID_CONF} ExecStart=/usr/sbin/squid -N $SQUID_OPTS -f ${SQUID_CONF} ExecReload=/usr/sbin/squid -k reconfigure -f ${SQUID_CONF} ExecStop=/usr/sbin/squid -k shutdown $SQUID_OPTS -f ${SQUID_CONF} # Note: Do NOT use ExecStop=/usr/sbin/squid -k shutdown -f ${SQUID_CONF} # because it doesn't wait for squid to exit, causing systemd to SIGKILL squid # right away which is certainly NOT what we want. # Instead, enjoy the SIGTERM default which is identical to "squid -k shutdown" # but without the nasty side effect of a (too early) SIGKILL. # # However per default, squid takes 30 seconds to exit which is acceptable but # quite a long time. Fortunately, this can easily be changed to 1 second in # /etc/squid/squid.conf: shutdown_lifetime 1 second [Install] WantedBy=multi-user.target
OK, I got the following to work, adapted mostly from the upstream one. I had to change it to Type=exec, as I think Type=notify only works if you compile it with systemd support. ## Copyright (C) 1996-2020 The Squid Software Foundation and contributors ## ## Squid software is distributed under GPLv2+ license and includes ## contributions from numerous individuals and organizations. ## Please see the COPYING and CONTRIBUTORS files for details. ## [Unit] Description=Squid Web Proxy Server Documentation=man:squid(8) After=network.target network-online.target nss-lookup.target [Service] EnvironmentFile=-/etc/sysconfig/squid Type=exec PIDFile=/run/squid.pid ExecStartPre=/usr/sbin/squid --foreground -z -F ExecStart=/usr/sbin/squid $SQUID_OPTS --foreground -sYC ExecReload=/usr/sbin/squid $SQUID_OPTS -k reconfigure KillMode=mixed NotifyAccess=all [Install] WantedBy=multi-user.target
Yeah, looking at the configure script, just adding BuildRequires: systemd-devel should be enough to get it to build systemd notify support.
I recommend patching the upstream service file to look like Comment 7 and adding the BuildRequires in Cauldron, and we can test these changes there for now and just push this 4.13 update for Mageia 7.
(In reply to David Walser from comment #9) > I recommend patching the upstream service file to look like Comment 7 and > adding the BuildRequires in Cauldron, and we can test these changes there > for now and just push this 4.13 update for Mageia 7. except leaving Type=notify as that should work once it's rebuilt.
Wrt the init script used up to now, the difference is the -N option used to create the cache. I'm not sure why it would solve a permission isue, but maybe that's to be tried as well.
I think it's a systemd timing issue because it will sometimes start with the init script after the boot if I restart it. We should switch to the systemd unit, but we can leave mga7 for now until it's gotten tested in Cauldron.
I submitted a version for cauldron that needs to be tested on a real cauldron system (my container doesn't allow me to use systemctl)
Submitted squid-4.13-2.mga7 to updates_testing Wrt the init script, I'm still unsure what happens, as that's what I used unmodified on a local machine here, and didn't encounter that issue.
Do you have /var on a separate partition? Please remember to use a release tag of 1 for new versions in updates.
Oh it is actually squid-4.13-1.mga7, nice! Advisory: ======================== Updated squid packages fix security vulnerabilities: An issue was discovered in Squid before 4.13. Due to incorrect data validation, HTTP Request Smuggling attacks may succeed against HTTP and HTTPS traffic. This leads to cache poisoning. This allows any client, including browser scripts, to bypass local security and poison the proxy cache and any downstream caches with content from an arbitrary source. When configured for relaxed header parsing (the default), Squid relays headers containing whitespace characters to upstream servers. When this occurs as a prefix to a Content-Length header, the frame length specified will be ignored by Squid (allowing for a conflicting length to be used from another Content-Length header) but relayed upstream (CVE-2020-15810). An issue was discovered in Squid before 4.13. Due to incorrect data validation, HTTP Request Splitting attacks may succeed against HTTP and HTTPS traffic. This leads to cache poisoning. This allows any client, including browser scripts, to bypass local security and poison the browser cache and any downstream caches with content from an arbitrary source. Squid uses a string search instead of parsing the Transfer-Encoding header to find chunked encoding. This allows an attacker to hide a second request inside Transfer-Encoding: it is interpreted by Squid as chunked and split out into a second request delivered upstream. Squid will then deliver two distinct responses to the client, corrupting any downstream caches (CVE-2020-15811). Squid before 4.13 and 5.x before 5.0.4 allows a trusted peer to perform Denial of Service by consuming all available CPU cycles during handling of a crafted Cache Digest response message. This only occurs when cache_peer is used with the cache digests feature. The problem exists because peerDigestHandleReply() livelocking in peer_digest.cc mishandles EOF (CVE-2020-24606). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15811 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24606 https://github.com/squid-cache/squid/security/advisories/GHSA-c7p8-xqhm-49wv https://github.com/squid-cache/squid/security/advisories/GHSA-vvj7-xjgq-g2jg https://github.com/squid-cache/squid/security/advisories/GHSA-3365-q9qx-f98m ======================== Updated packages in core/updates_testing: ======================== squid-4.13-1.mga7 squid-cachemgr-4.13-1.mga7 from squid-4.13-1.mga7.src.rpm
CC: (none) => brunoAssignee: bruno => qa-bugs
Updated version is functional (tested on two x86_64 systems).
Whiteboard: (none) => MGA7-64-OKCC: (none) => sysadmin-bugsKeywords: (none) => validated_update
(In reply to David Walser from comment #15) > Do you have /var on a separate partition? Yes, and /var/spool/squid is also another separate partition in my case.
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0361.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED