Fedora has issued an advisory on October 31: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/B3OBLEH47QRUDDGH3YDMJ3SNT3D5LLDB/ The upstream advisory from October 21: https://varnish-cache.org/security/VSV00004.html says it is fixed upstream in 6.3.1 (in Cauldron) and 5.x is affected.
No registered maintainer, but DavidG has done all recent commits, so assigning to you. Beware: > fixed upstream in 6.3.1 (in Cauldron) and 5.x is affected
Assignee: bugsquad => geiger.david68210
Done!
Advisory: ======================== Updated varnish packages fix security vulnerability: A bug has been discovered in Varnish Cache where we fail to clear a pointer between the handling of one client requests and the next on the same connection. This can under specific circumstances lead to information being leaked from the connection workspace (VSV00004). The varnish package has been updated to version 6.3.1, which includes many fixes and enhancements. See the upstream documentation for details. References: https://varnish-cache.org/security/VSV00004.html https://varnish-cache.org/docs/6.3/whats-new/index.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/B3OBLEH47QRUDDGH3YDMJ3SNT3D5LLDB/ ======================== Updated packages in core/updates_testing: ======================== varnish-6.3.1-1.mga7 libvarnish2-6.3.1-1.mga7 libvarnish-devel-6.3.1-1.mga7 from varnish-6.3.1-1.mga7.src.rpm
CC: (none) => geiger.david68210Assignee: geiger.david68210 => qa-bugs
Mageia7, x86_64 varnish is a caching server which sits between the user and the webserver, which with continued use speeds up web transactions by taking some of the load off the backend (webserver). Its own cache resides in RAM whose size can be specified at startup time. The configuration file defaults to /etc/varnish/default.vcl. Installed varnish to make sure it works before the update. Copy the process id and assign 512MB to the cache. # varnishd -f '' -a :6081 -P /var/run/varnish.pid -s malloc,512m Debug: Platform: Linux,5.4.6-desktop-2.mga7,x86_64,-junix,-smalloc,-smalloc,-hcritbit This actually spawns two processes one of which is the manager process. # pgrep -lf varnish 9714 varnishd # cat /var/run/varnish.pid 9714 # kill -9 `cat /var/run/varnish.pid` or # kill -9 9714 That stops varnish. Started it up again as root and in two other terminals started varnishlog and varnishstat as a user. Both of these timed out eventually with ..... Could not get hold of varnishd, is it running? Also - # GET -Used http://localhost:6081/ GET http://localhost:6081/ User-Agent: lwp-request/6.38 libwww-perl/6.38 500 Can't connect to localhost:6081 (Connection refused) Content-Type: text/plain Client-Date: Sat, 04 Jan 2020 20:20:40 GMT Client-Warning: Internal response Note that 6081 is enabled in the firewall for TCP and UDP. # GET -Used http://localhost:6081/ GET http://localhost:6081/ User-Agent: lwp-request/6.38 libwww-perl/6.38 500 Can't connect to localhost:6081 (Connection refused) Content-Type: text/plain Client-Date: Sat, 04 Jan 2020 20:20:40 GMT Client-Warning: Internal response Logged in as root on the two other terminals and ran varnishlog and varnishstat. The former printed out: Log abandoned and the other showed zero hits for the management process and "Not running" for the Uptime child process. Shall try all this again after updating.
CC: (none) => tarazed25
Updated packages from core updates testing. Restarted the varnish server. # varnishlog [...] Log abandoned (vsm) <continuous stream of these messages> # varnishstat Uptime mgt: 0+00:04:41 Hitrate n: 0 0 0 Uptime child: Not Running avg(n): 0.0000 0.0000 0.0000 NAME CURRENT CHANGE AVERAGE AVG_10 MGT.uptime 0+00:04:41 # pgrep -lf varnish <No pid returned> # ps aux | grep varnish varnish 7248 0.0 0.0 26192 4032 ? SLs 00:29 0:00 varnishd -f -a :6081 -P /var/run/varnish.pid -s malloc,512m root 7316 0.0 0.0 4428 1196 pts/5 S+ 00:30 0:00 varnishlog root 7425 0.0 0.0 5296 3192 pts/1 S+ 00:31 0:00 varnishstat # GET -Used http://localhost:6081/ GET http://localhost:6081/ User-Agent: lwp-request/6.38 libwww-perl/6.38 500 Can't connect to localhost:6081 (Connection refused) Content-Type: text/plain Client-Date: Sun, 05 Jan 2020 00:32:07 GMT Client-Warning: Internal response So, something seems to have gone wrong - no idea what.
Starting over on another machine - installed and updated varnish. The Linux Journal tutorial used first does not match up with the official documentation. For a start, varnish is amenable to systemd. Edited the default.vcl to point to the varnish website and started the service via systemd. # systemctl status varnish ● varnish.service - Varnish a high-perfomance HTTP accelerator Loaded: loaded (/usr/lib/systemd/system/varnish.service; disabled; vendor pr> Active: active (running) since Sun 2020-01-05 12:22:18 GMT; 14s ago .... Tried http:/localhost:6081 in firefox. "Sorry, we moved! We moved the Varnish Project to a new server a lot of old links are not quite ready yet, but we're working on fixing that. Try starting from the frontpage" That looks encouraging. Followed the link and ended up at https://varnish-cache.org/ Started varnishlog and varnishstat in separate terminals. The statistics display showed: Uptime mgt: 0+00:07:36 Hitrate n: 10 100 429 Uptime child: 0+00:07:37 avg(n): 0.0000 0.0004 0.0023 NAME CURRENT CHANGE AVERAGE AVG_10 MGT.uptime 0+00:07:36 MAIN.uptime 0+00:07:37 MAIN.sess_conn 2 0.00 0.00 0.00 MAIN.client_req 2 0.00 0.00 0.00 MAIN.cache_hit 1 0.00 0.00 0.00 MAIN.cache_miss 1 0.00 0.00 0.00 MAIN.backend_conn 1 0.00 0.00 0.00 MAIN.backend_recycle 1 0.00 0.00 0.00 MAIN.fetch_length 1 0.00 0.00 0.00 MAIN.pools 2 0.00 . 2.00 MAIN.threads 10 0.00 . 10.00 MAIN.threads_created 10 0.00 0.02 0.00 MAIN.n_object 0 0.00 . 0.00 MAIN.n_objectcore 1 0.00 . 1.00 MAIN.n_objecthead 2 0.00 . 2.00 MAIN.n_backend 1 0.00 . 1.00 vvv MGT.uptime INFO 1-16/40 Assuming all that is OK. # GET -Used http://localhost:6081/ GET http://localhost:6081/ User-Agent: lwp-request/6.38 libwww-perl/6.38 404 Not Found Connection: close Date: Sun, 05 Jan 2020 12:46:57 GMT Via: 1.1 varnish (Varnish/6.3) Age: 50 Server: Varnish Content-Length: 359 Client-Date: Sun, 05 Jan 2020 12:48:03 GMT Client-Peer: 127.0.0.1:6081 Client-Response-Num: 1 X-Varnish: 2702371 X-Varnish: 5 3 Assuming here that the 404 error arises because the site has moved. The logging terminal shows: * << BeReq >> 3 - Begin bereq 2 fetch - VCL_use boot - Timestamp Start: 1578228432.079983 0.000000 0.000000 - BereqMethod GET - BereqURL / - BereqProtocol HTTP/1.1 - BereqHeader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 - Fetch_Body 3 length stream - BackendReuse 28 boot.default - Timestamp BerespBody: 1578227712.088066 0.068598 0.000140 - Length 359 - BereqAcct 152 0 152 145 359 504 - End [...] * << Session >> 4 - Begin sess 0 HTTP/1 - SessOpen 127.0.0.1 46862 a0 127.0.0.1 6081 1578228483.070994 24 - Link req 5 rxreq - SessClose REQ_CLOSE 0.011 - End This is as far as I can take this. My impression is that the whole thing works but an expert might disagree. Leaving it running anyway. Allowing a tentative OK.
Whiteboard: (none) => MGA7-64-OK
As long as you are letting it run for a while, I'll give it a couple of days before validating. If you don't report any problems, I'll send it on.
CC: (none) => andrewsfarm
D'accord.
OK TJ, validating this.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0025.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
This has been assigned CVE-2019-20637: https://lists.opensuse.org/opensuse-updates/2020-06/msg00058.html
Summary: varnish new security issue VSV00004 => varnish new security issue VSV00004 (CVE-2019-20637)