Debian has issued an advisory on February 18: https://www.debian.org/security/2015/dsa-3162 Updated packages uploaded for Mageia 4 and Cauldron. Advisory: ======================== Updated bind packages fix security vulnerability: Jan-Piet Mens discovered that the BIND DNS server would crash when processing an invalid DNSSEC key rollover, either due to an error on the zone operator's part, or due to interference with network traffic by an attacker. This issue affects configurations with the directives "dnssec-lookaside auto;" (as enabled in the Mageia default configuration) or "dnssec-validation auto;" (CVE-2015-1349). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1349 https://kb.isc.org/article/AA-01235 https://kb.isc.org/article/AA-01245 https://www.debian.org/security/2015/dsa-3162 ======================== Updated packages in core/updates_testing: ======================== bind-9.9.6.P2-1.mga4 bind-sdb-9.9.6.P2-1.mga4 bind-utils-9.9.6.P2-1.mga4 bind-devel-9.9.6.P2-1.mga4 bind-doc-9.9.6.P2-1.mga4 from bind-9.9.6.P2-1.mga4.src.rpm Reproducible: Steps to Reproduce:
Testing procedure: similar to https://bugs.mageia.org/show_bug.cgi?id=9163#c8
Whiteboard: (none) => has_procedure
Testing on Mageia 4x32 real hardware following procedure mentioned in Comment 1 Did not find PoCs. From current packages : --------------------- bind-9.9.6.P1-1.mga4 bind-sdb-9.9.6.P1-1.mga4 bind-utils-9.9.6.P1-1.mga4 bind-devel-9.9.6.P1-1.mga4 bind-doc-9.9.6.P1-1.mga4 # dig @localhost mageia.org # dig @localhost 217.70.188.116 To updated testing packages : --------------------------- bind-9.9.6.P2-1.mga4 bind-sdb-9.9.6.P2-1.mga4 bind-utils-9.9.6.P2-1.mga4 bind-devel-9.9.6.P2-1.mga4 bind-doc-9.9.6.P2-1.mga4 # systemctl restart named # systemctl status -l named # dig @localhost mageia.org # dig @localhost 217.70.188.116 No problem during installation, no regression found : OK
CC: (none) => olchalWhiteboard: has_procedure => has_procedure MGA4-32-OK
Some warnings when updating, something to do with the chroot.. 2/4: bind ######## mv: â/var/lib/named/var/named/dataâ and â/var/named/dataâ are the same file mv: â/var/lib/named/var/named/dynamicâ and â/var/named/dynamicâ are the same file mv: â/var/lib/named/var/named/named.caâ and â/var/named/named.caâ are the same file mv: â/var/lib/named/var/named/named.emptyâ and â/var/named/named.emptyâ are the same file mv: â/var/lib/named/var/named/named.localhostâ and â/var/named/named.localhostâ are the same file mv: â/var/lib/named/var/named/named.loopbackâ and â/var/named/named.loopbackâ are the same file mv: â/var/lib/named/var/named/slavesâ and â/var/named/slavesâ are the same file It appears to load the zones ok though and no regression in simple testing.
Whiteboard: has_procedure MGA4-32-OK => has_procedure feedback MGA4-32-OK mga4-64-ok?
It's just moving zone files from the old location to the new one, which is already bind mounted if the service is already running, so you see those messages. It doesn't hurt anything. I could drop that part of the scriplet in Cauldron.
Whiteboard: has_procedure feedback MGA4-32-OK mga4-64-ok? => has_procedure feedback MGA4-32-OK mga4-64-ok
Testing on Mageia4x64 real hardware, bearing in mind Claire's comment 3 From current packages : --------------------- bind-9.9.6.P1-1.mga4 bind-utils-9.9.6.P1-1.mga4 # systemctl -status named showed named running error free # dig @localhost mageia.org # dig @localhost 217.70.188.116 gave expected results Tried to dig to virtualmachine in local network : # dig @localhost vmag464.zitoun.net ; <<>> DiG 9.9.6-P1 <<>> @localhost vmag464.zitoun.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9414 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;vmag464.zitoun.net. IN A ;; ANSWER SECTION: vmag464.zitoun.net. 86400 IN A 192.168.0.14 ;; AUTHORITY SECTION: zitoun.net. 86400 IN NS mageialan.zitoun.net. ;; ADDITIONAL SECTION: mageialan.zitoun.net. 86400 IN A 192.168.0.11 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: sam. févr. 21 15:00:40 CET 2015 ;; MSG SIZE rcvd: 103 OK there too. To updated testing packages : --------------------------- bind-9.9.6.P2-1.mga4 bind-utils-9.9.6.P2-1.mga4 This time, I used urpmi (not MCC) and got equivalent messages that Claire encountered : mv: « /var/lib/named/var/named/data » et « /var/named/data » identifient le même fichier mv: « /var/lib/named/var/named/dynamic » et « /var/named/dynamic » identifient le même fichier (...) After restarting named, # dig @localhost mageia.org # dig @localhost 217.70.188.116 # dig @localhost vmag464.zitoun.net $ ping -c 4 vmag464.zitoun.net (ping from host to Vbox guest on lan) $ ping -c 4 mageialan.zitoun.net (ping from vbox guest to host on lan) Were OK and gave expected results
Could perhaps redirect the output David, wdyt? I'm happy to validate it and create a new bug if you like.
Advisory uploaded.
Whiteboard: has_procedure feedback MGA4-32-OK mga4-64-ok => has_procedure advisory MGA4-32-OK mga4-64-ok
Don't worry about the message. It doesn't happen if it's not running.
Also, you don't want to silence it in case there are any legitimate errors when upgrading from earlier versions. The bind mounting makes for some weird things that you can't easily get around.
Bug 15336 created for the warnings. We shouldn't see warnings with updates without good reason. Extra logic can be added to perform checks if it's desired to highlight issues at this stage. Validating. Please push to 4 updates. Thanks.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0082.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Just an observation: My nameserver's configuration is mostly in /var/lib/named/var/named/ (under the chrooted part of the filesystem). Previous BIND updates have installed without affecting my configuration. This update somehow lost all my config with the exception of: /etc/named.conf /var/lib/named/etc/bogon_acl.conf /var/lib/named/etc/trusted_networks_acl.conf /var/lib/named/etc/logging.conf I had to recover my nameserver config from backup.
CC: (none) => paul.blackburn
There was nothing special about this update that would have done that, but this package is flaky in general since we synced it with Fedora. The way it used to be worked a lot better.
I have a similar problem like mentioned in Comment 12. After installing the update at night by nameservice was dead. It failed on restart Feb 23 04:03:35 testido systemd[1]: named.service: control process exited, code=exited status=1 Feb 23 04:03:35 testido systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). I investigated into that problem and found that "named-checkconf" executed by systemd faild. Finding the problem is not easy, because "named-checkconf" itself does not provide any hint to the error but I found that that the switch from /var/lib/named/var/named/ to /var/named/ cause the problem. Before this update the file "named.ca" for example was located in /var/lib/named/var/named/ and after the update it is in /var/named/ While the named.conf (which is normally changed by user) is not adapted during this update the service must fail on restart because of missing zone configurations. Why is such a change made during a security update without giving a hint (or did I miss anything)? Name service is one of the most important services so doing such a change should be made very carefully!
CC: (none) => s.puch
BIND normally runs chrooted under /var/lib/named/ So the config files used are in: /var/lib/named/var/named/ (sidenote: I have to recover my config files from backup after this update). I verified this on my nameserver by making a change to my config under /var/lib/named/var/named/ and testing a DNS lookup which confirmed the change. At the same time, I observe there is a pre-change copy of the config files in /var/lib/named/ but these are not the "live" config files that are being used by the running named. I guess the copy in /var/named/ was made by the update for 15326.
oopsie: correction to comment 15. At the same time, I observe there is a pre-change copy of the config files in /var/lib/named/ but these are not the "live" config files that are being used by the running named. should be: At the same time, I observe there is a pre-change copy of the config files in * /var/named/ * but these are not the "live" config files that are being used by the running named.
(In reply to Stefan Puch from comment #14) > Why is such a change made during a security update without giving a hint (or > did I miss anything)? Name service is one of the most important services so > doing such a change should be made very carefully! Like I said, *nothing* was changed in this update! It was just updating to 9.9.6-P2 from 9.9.6-P1, that's it. Your zone files are stored in /var/named, which is then bind mounted to /var/lib/named/var/named when the service is run. If you have errors in your named.conf (which would be your fault, not the package's), the service will fail, but it will still leave all of the bind mounts mounted (which is the package's fault), and you have to manually umount all of them before attempting to restart the service. Like I said, syncing this package with Fedora made it kind of flaky unfortunately, the way the chroot and bind mounting is handled is not ideal. We already have Bug 10994 for this. Please cease discussing it in this bug.