Security update for bind crashing after errors detected causing a denial of service.
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC.
CC: (none) => balcaen.john, guillomovitch, misc, pterjan
Ping .
It would be nice to get this security fix. Mandriva has issued it, and it looks like updating 9.8.1-P1 or newer would be sufficient to fix it. http://lists.mandriva.com/security-announce/2011-11/msg00030.php
CC: (none) => luigiwalser
Updated advisory: http://lists.mandriva.com/security-announce/2011-11/msg00032.php
Suggested advisory: ======================== Updated bind packages fix a security vulnerability: It was found that BIND allows remote attackers to cause a denial of service (assertion failure and named exit) via vectors related to recursive DNS queries, error logging, and the caching of an invalid record by the resolver. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4313 http://www.debian.org/security/2011/dsa-2347 http://www.isc.org/software/bind/advisories/cve-2011-4313 ======================== Updated packages in core/updates_testing: ===================== bind-9.8.1P1-1.mga1 bind-devel-9.8.1P1-1.mga1 bind-doc-9.8.1P1-1.mga1 bind-utils-9.8.1P1-1.mga1 from bind-9.8.1P1-1.mga1 src.rpm. =====================
Keywords: (none) => SecurityStatus: NEW => ASSIGNEDCC: (none) => anssi.hannulaHardware: i586 => AllAssignee: bugsquad => qa-bugs
CC: balcaen.john, guillomovitch, misc, pterjan => (none)
With this update installed, named is taking all available cpu time.
Hmm, it works fine here with default settings. What kind of config are you using? Also, if you could install bind-debug and attach gdb to it ("gdb -p $PID") and then have a backtrace of all threads ("thread apply all bt"), it'd be helpful in determining what is triggering the issue.
Dave, is this on the 2.6.38.8-9 kernel also ?
CC: (none) => tmb
Created attachment 1308 [details] Backtrace of named uname -r 2.6.38.8-server-9.mga I'll attach the config files.
Created attachment 1309 [details] named.conf
Created attachment 1310 [details] adblock.conf
Attachment 1310 mime type: application/octet-stream => text/plain
Created attachment 1311 [details] bogon_acl.conf
Created attachment 1312 [details] db.adblock
Reproduced with the given config files, I'll investigate soon.
Assignee: qa-bugs => anssi.hannula
The trigger seems to be the managed-keys clause in Dave's named.conf. Even cauldron bind will go to 100% cpu usage when one adds the managed-keys entry on top of default configuration.
Interesting regression, especially as I'd turned off dnssec, since I was having problems with some web sites, and turned it off to see if it was a factor. I just tried turning it back on, but it's still using all available cpu.
fedora 15 bind 9.8.2b1 on cauldron: works bind 9.8.2b1 using our pkg on cauldron: fails bind 9.8.1-P1 built manually from source without changes, on cauldron: fails
Correction, I accidentally tested f15 9.8.0-P1 above, so it working is expected. f15 9.8.1-P1 on cauldron fails. Does someone have access to a fedora installation to see if our named.conf + managed-keys clause causes issues there, or if it is caused by our environment?
The issue is fixed by chowning /var/lib/named/var/named to named so that named can write "managed-keys.bind.jnl" there. However, fedora doesn't seem to be doing that. Guillaume, Pascal, you are much more familiar with named, WDYT?
CC: (none) => guillomovitch, pterjan
Fedora has managed-keys-directory "/var/named/dynamic" in named.conf, and that directory is named-writable. However, that doesn't help existing mga1 installations which we want to upgrade to 9.8.1-P1... Of course, 100% CPU usage isn't probably nice error behaviour on unwritable directory, so we should probably see if that regression can be fixed...
Anssi: why is Dave's configuration like that? Is it the default in the Mageia package? My named configuration on MDV 2010.2 is like you described for Fedora.
David: managed-keys-directory doesn't exist in Mageia default configuration. In MDV 2010.2 it was only added with the latest security update, it wasn't there originally. managed-keys is a clause that Dave had added himself. For the record, I've just reported this issue to bind9-bugs@.
(In reply to comment #21) > Anssi: why is Dave's configuration like that? Is it the default in the Mageia > package? My named configuration on MDV 2010.2 is like you described for > Fedora. Yes, I added dnssec validation to my config. While it isn't the default in a standard Mageia install of bind, it works in the prior version, so this is a regression. Confirming "chown named:named /var/lib/named/var/named" fixes the problem. Strange that it didn't cause a problem before.
Upstream reported back that the issue is already reported as RT #27076 and will be addressed in an (unspecified) future release. Maybe we should just add the /dynamic directory and perform a sed hack on the config file? I'm still waiting for any input from mga bind packagers.
From what I understand by reading this report, the permission issue is unrelated to the original DOS, and shouldn't block the release of a security update. This is a recurrent trend than every security update get blocked by QA because of additional secondary issues, which just shows than updates are more tested than packages from the stable release... This permission issue could also get fixed in the update package, either by changing ownership of /var/lib/named/var/named in the %file list, or by using another dedicated subdirectory, such as /var/lib/named/var/named/dynamic, with a suitable managed-keys-directory directive in configuration. Changing current configuration on the fly during %post seems a bad idea, as it breaks general expectation than package don't mess with configuration after initial installation.
Thanks. The permission issue is unrelated, yes, but there is a regression in the update: The permission issue was previously handled gracefully, but now bind goes to infinite loop or similar, causing 100% CPU usage. I'd side on adding /dynamic to follow other distros. However, as noted, this won't help current users. Should we maybe do both, i.e. change default configuration to use a /dynamic and change perms of /var/lib/named/var/named to account for upgrades? Do you think changing ownership of /var/lib/named/var/named is safe? Other distros IIRC have it like we have now, i.e. root:root.
Adding /var/lib/named/var/named/dynamic, changing default configuration, and mentionning the issue in the release advisory should be enough for people to take care of managing their own running configuration if needed. This only affect people using dnssec, after all.
As there's an easy workaround, and only people who enabled dnssec are affected, I'm not against pushing this update, and letting the proper fix come from upstream later. Has the update been tested on x86-64 yet?
I'll look into implementing Guillaume's suggestion soon (tomorrow?), unless someone does it before me.
Ping. Should we push this update? Has it been tested on x86-64?
Sorry for the delay. Updated suggested advisory: ======================== Updated bind packages fix a security vulnerability: It was found that BIND allows remote attackers to cause a denial of service (assertion failure and named exit) via vectors related to recursive DNS queries, error logging, and the caching of an invalid record by the resolver. Note that the updated version of BIND does not handle unwritable managed keys directory gracefully. If you have customized named.conf and enabled dnssec, you may need to add the following line into the 'options' section: managed-keys-directory "/var/named/dynamic"; This has also been added to the default configuration file. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4313 http://www.debian.org/security/2011/dsa-2347 http://www.isc.org/software/bind/advisories/cve-2011-4313 ======================== Updated packages in core/updates_testing: ===================== bind-9.8.1P1-1.1mga1 bind-devel-9.8.1P1-1.1mga1 bind-doc-9.8.1P1-1.1mga1 bind-utils-9.8.1P1-1.1mga1 from bind-9.8.1P1-1.1mga1 src.rpm. =====================
Could someone from the sysadmin team push the srpm bind-9.8.1P1-1.mga1.src.rpm from Core Updates Testing to Core Updates. Advisory: Updated bind packages fix a security vulnerability: It was found that BIND allows remote attackers to cause a denial of service (assertion failure and named exit) via vectors related to recursive DNS queries, error logging, and the caching of an invalid record by the resolver. Note that the updated version of BIND does not handle unwritable managed keys directory gracefully. If you have customized named.conf and enabled dnssec, you may need to add the following line into the 'options' section: managed-keys-directory "/var/named/dynamic"; This has also been added to the default configuration file. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4313 http://www.debian.org/security/2011/dsa-2347 http://www.isc.org/software/bind/advisories/cve-2011-4313 https://bugs.mageia.org/show_bug.cgi?id=3379
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
That is the advisory for bind-9.8.1P1-1.1mga1, not bind-9.8.1P1-1.mga1 (see comment #31).
update pushed.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED