Date: Fri, 19 Jan 2018 11:47:21 +0100 From: Ralph Dolmans <ralph@...etlabs.nl> To: oss-security@...ts.openwall.com Subject: CVE-2017-15105 Unbound: NSEC processing vulnerability (DNSSEC) Hi, Below is a copy of Unbound's CVE description that can be found at https://unbound.net/downloads/CVE-2017-15105.txt Regards, Ralph == The CVE number for this vulnerability is CVE-2017-15105. == Summary We discovered a vulnerability in the processing of wildcard synthesized NSEC records. While synthesis of NSEC records is allowed by RFC4592, these synthesized owner names should not be used in the NSEC processing. This does, however, happen in Unbound 1.6.7 and earlier versions. == Description NSEC records are used to prove the non-existence of records between its owner name and its next owner, and for the proof that the queried for type does not exist when the queried for name matches the owner of the NSEC. It is therefore important that the owner name of the NSEC record can not be changed, this is enforced using a DNSSEC signature (RRSIG). Because wildcard synthesis on NSEC records is allowed, it is possible to have DNSSEC valid NSEC records for which the owner name must not be used for non-existence proofs. A validator can determine that it is a wildcard record using the label count in the NSEC signature and must in that case use the non-synthesized wildcard name as NSEC owner. Unbound validates these NSEC records (using the label count), and then uses the owner of the NSEC it received for the non-existence proof. Unbound is only vulnerable for zones that contain a wildcard record and use NSEC records for the non-existence proof. NSEC3 records do not work for this attack. == Impact The wildcard NSEC record can be used to proof the non-existence (NXDOMAIN answer) of an existing wildcard record. This can be done by changing the owner of the wildcard NSEC into a label that will be sorted before the wildcard label. The wildcard NSEC record can also be used to trick Unbound into accepting a NODATA proof. This can be done by changing the owner name of the NSEC wildcard record into the queried for name. This is only possible when the queried for type is not in the type bitmap of the NSEC wildcard record. This vulnerability can not be used to trick Unbound into accepting an insecure delegation proof (proof of no DS). The NS bit must be set in the NSEC type bitmap when proving an insecure delegation, this is never the case for wildcard records. == Solution Download patched version of Unbound, or apply the patch manually. + Downloading patched version Unbound 1.6.8 is released with the patch https://unbound.net/downloads/unbound-1.6.8.tar.gz + Applying the Patch manually For Unbound version 1.6.7 the patch is: https://unbound.net/downloads/patch_cve_2017_15105.diff Apply the patch on Unbound source directory with 'patch -p0 < filename' then run 'make install' to install Unbound. == Acknowledgements Ralph Dolmans (NLnet Labs) Karst Koymans (University of Amsterdam)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.