Prevents a crash when queried for a record whose RDATA exceeds
65535 bytes.
Prevents a crash when validating caused by using "Bad cache" data
before it has been initialized.
ISC_QUEUE handling for recursive clients was updated to address
a race condition that could cause a memory leak. This rarely
occurred with UDP clients, but could be a significant problem
for a server handling a steady rate of TCP queries.
A condition has been corrected where improper handling of
zero-length RDATA could cause undesirable behavior, including
termination of the named process.
For more information: https://kb.isc.org/article/AA-00788
in BIND9
High numbers of queries with DNSSEC validation enabled can cause an
assertion failure in named, caused by using a "bad cache" data structure
before it has been initialized.
CVE: CVE-2012-3817
Posting date: 24 July, 2012
a critical bugfix:
Processing of DNS resource records where the rdata field is zero length
may cause various issues for the servers handling them.
Processing of these records may lead to unexpected outcomes. Recursive
servers may crash or disclose some portion of memory to the client.
Secondary servers may crash on restart after transferring a zone
containing these records. Master servers may corrupt zone data if the
zone option "auto-dnssec" is set to "maintain". Other unexpected
problems that are not listed here may also be encountered.
All BIND users are strongly encouraged to upgrade.
Feature Change
* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
Bug Fix
* The locking strategy around the handling of iterative queries
has been tuned to reduce unnecessary contention in a multi-
threaded environment.
Other critical bug fixes are included.
All BIND users are encouraged to upgrade.
Recursive name servers are failing with an assertion:
INSIST(! dns_rdataset_isassociated(sigrdataset))
At this time it is not thought that authoritative-only servers
are affected, but information about this bug is evolving rapidly.
Because it may be possible to trigger this bug even on networks
that do not allow untrusted users to access the recursive name
servers (perhaps via specially crafted e-mail messages, and/or
malicious web sites) it is recommended that ALL operators of
recursive name servers upgrade immediately.
For more information see:
https://www.isc.org/software/bind/advisories/cve-2011-tbd
which will be updated as more information becomes available.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4313
ALL BIND USERS ARE ENCOURAGED TO UPGRADE IMMEDIATELY
This update addresses the following vulnerability:
CVE-2011-2464
=============
Severity: High
Exploitable: Remotely
Description:
A defect in the affected BIND 9 versions allows an attacker to remotely
cause the "named" process to exit using a specially crafted packet. This
defect affects both recursive and authoritative servers. The code location
of the defect makes it impossible to protect BIND using ACLs configured
within named.conf or by disabling any features at compile-time or run-time.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2464https://www.isc.org/software/bind/advisories/cve-2011-2464
1. Very large RRSIG RRsets included in a negative cache can trigger
an assertion failure that will crash named (BIND 9 DNS) due to an
off-by-one error in a buffer size check.
This bug affects all resolving name servers, whether DNSSEC validation
is enabled or not, on all BIND versions prior to today. There is a
possibility of malicious exploitation of this bug by remote users.
2. Named could fail to validate zones listed in a DLV that validated
insecure without using DLV and had DS records in the parent zone.
Add a patch provided by ru@ and confirmed by ISC to fix a crash at
shutdown time when a SIG(0) key is being used.
All 9.6 users with DNSSEC validation enabled should upgrade to this
version, or the latest version in the 9.7 branch, prior to 2011-03-31
in order to avoid validation failures for names in .COM as described
here:
https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record
In addition the fixes for this and other bugs, there are also the
following:
* Various fixes to kerberos support, including GSS-TSIG
* Various fixes to avoid leaking memory, and to problems that could
prevent a clean shutdown of named
the problems related to the handling of broken DNSSEC trust chains.
This fix is only relevant for those who have DNSSEC validation
enabled and configure trust anchors from third parties, either
manually, or through a system like DLV.
security patches to the 9.6.1 version, as well as many other bug fixes.
This version also incorporates a different fix for the problem we had
patched in contrib/bind9/bin/dig/dighost.c, so that file is now back
to being the same as the vendor version.
Due to the fact that the DNSSEC algorithm that will be used to sign the
root zone is only included in this version and in 9.7.x those who wish
to do validation MUST upgrade to one of these prior to July 2010.
related to DNSSEC validation on a resolving name server that allows
access to untrusted users. If your system does not fall into all 3 of
these categories you do not need to update immediately.
changes from the 9.6.1rc1 version. The first 2 only affect DNSSEC.
named could incorrectly delete NSEC3 records for
empty nodes when processing a update request.
Accept DS responses from delegation only zones.
"delegation-only" was not being accepted in
delegation-only type zones.
permanent solution for 9.6.1-release.
"My suggestion is to remove the whole attribute construct.
It only suppresses a warning when a function is unused. In this case
the function is defined as inline, so it's not causing a warning when
not used."
Submitted by: marcel
lots of new features compared to 9.4.x, including:
Full NSEC3 support
Automatic zone re-signing
New update-policy methods tcp-self and 6to4-self
DHCID support.
More detailed statistics counters including those supported in BIND 8.
Faster ACL processing.
Efficient LRU cache-cleaning mechanism.
NSID support.
the patch from ISC for lib/bind9/check.c and deletion of unused
files in lib/bind.
This version will by default randomize the UDP query source port
(and sequence number of course) for every query.
In order to take advantage of this randomization users MUST have an
appropriate firewall configuration to allow UDP queries to be sent and
answers to be received on random ports; and users MUST NOT specify a
port number using the query-source[-v6] options.
The avoid-v[46]-udp-ports options exist for users who wish to eliminate
certain port numbers from being chosen by named for this purpose. See
the ARM Chatper 6 for more information.
Also please note, this issue applies only to UDP query ports. A random
ephemeral port is always chosen for TCP queries.
This issue applies primarily to name servers whose main purpose is to
resolve random queries (sometimes referred to as "caching" servers, or
more properly as "resolving" servers), although even an "authoritative"
name server will make some queries, primarily at startup time.
All users of BIND are strongly encouraged to upgrade to the latest
version, and to utilize the source port randomization feature.
This update addresses issues raised in:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447http://www.kb.cert.org/vuls/id/800113http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience
The problem was, isc_atomic_cmpxchg() is almost like our
atomic_cmpset_32(), except it expects the old value to be
returned, whereas our atomic_cmpset_32 returns 1 on success,
or 0 on failure. So I re-implemented something suitable.
Submitted by: cognet
Reviewed by: bsdimp
1. The default access control lists (acls) are not being
correctly set. If not set anyone can make recursive queries
and/or query the cache contents.
See also:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2925
2. The DNS query id generation is vulnerable to cryptographic
analysis which provides a 1 in 8 chance of guessing the next
query id for 50% of the query ids. This can be used to perform
cache poisoning by an attacker.
This bug only affects outgoing queries, generated by BIND 9 to
answer questions as a resolver, or when it is looking up data
for internal uses, such as when sending NOTIFYs to slave name
servers.
All users are encouraged to upgrade.
See also:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926
Approved by: re (kensmith, implicit)
announced by ISC dated 31 October (delivered via e-mail to the
bind-announce@isc.org list on 2 November):
Description:
Because of OpenSSL's recently announced vulnerabilities
(CAN-2006-4339, CVE-2006-2937 and CVE-2006-2940) which affect named,
we are announcing this workaround and releasing patches. A proof of
concept attack on OpenSSL has been demonstrated for CAN-2006-4339.
OpenSSL is required to use DNSSEC with BIND.
Fix for version 9.3.2-P1 and lower:
Upgrade to BIND 9.3.2-P2, then generate new RSASHA1 and
RSAMD5 keys for all old keys using the old default exponent
and perform a key rollover to these new keys.
These versions also change the default RSA exponent to be
65537 which is not vulnerable to the attacks described in
CAN-2006-4339.
part of the structure was a hack to maintain binary compatibility with
Sun binaries, and my understanding is that it's not needed generally
on sparc systems running other operating systems. Therefore, hide this
code behind the same set of tests as in lib/bind/include/netdb.h.
This file is being imported on the vendor branch because a similar change
(or change with similar effect) will be in the next version of BIND 9.
This change will not affect other platforms in any way.
researched by glebius, and incorporated by ISC into the next
version of BIND. Unfortunately, it looks like their release
will come after the release of FreeBSD 6, so we will bring
this in now.
The patch addresses a problem with high-load resolvers which
hit memory barriers. Without this patch, running the resolving
name server out of memory would lead to "unpredictable results."
Of course, the canonical answer to this problem is to put more
memory into the system, however that is not always possible, and
the code should be able to handle this situation gracefully in
any case.
