* Addresses could be referenced after being freed during resolver
processing, causing an assertion failure. The chances of this happening
were remote, but the introduction of a delay in resolution increased
them. (The delay will be addressed in an upcoming maintenance release.)
This bug is disclosed in CVE-2017-3145. [RT #46839]
9.10.5-P2 broke verification of TSIG signed TCP message sequences where
not all the messages contain TSIG records. These may be used in AXFR and
IXFR responses. [RT #45509]
An error in TSIG handling could permit unauthorized zone transfers
or zone updates. CVE-2017-3142, CVE-2017-3143.
Also updates the address of b.root in hints.
* With certain RPZ configurations, a response with TTL 0 could cause
named to go into an infinite query loop. This flaw is disclosed in
CVE-2017-3140. [RT #45181]
A server is potentially vulnerable to degradation of service if
1. the server is configured to use RPZ,
2. the server uses NSDNAME or NSIP policy rules, and
3. an attacker can cause the server to process a specific query
CVE-2017-3136: An error handling synthesized records could cause an
assertion failure when using DNS64 with "break-dnssec yes;"
CVE-2017-3137: A response packet can cause a resolver to terminate when
processing an answer containing a CNAME or DNAME
CVE-2017-3138: named exits with a REQUIRE assertion failure if it receives
a null command string on its control channel
* If a server is configured with a response policy zone (RPZ) that
rewrites an answer with local data, and is also configured for DNS64
address mapping, a NULL pointer can be read triggering a server crash.
This flaw is disclosed in CVE-2017-3135. [RT #44434]
* A synthesized CNAME record appearing in a response before the associated
DNAME could be cached, when it should not have been. This was a
regression introduced while addressing CVE-2016-8864. [RT #44318]
pledge is "stdio rpath inet unix dns", dropping to "stdio inet dns"
after argument parsing.
access to resolv.conf is required late; the dns pledge is used for this
rather than requiring full rpath; however contrary to the version in
base, inet is allowed as well, so that it can be used as a debug tool
for servers on alternate ports.
works fine for me; no feedback after posting yet so committing to get
real-world testing. please report any issues.
Named could mishandle authority sections that were missing RRSIGs triggering
an assertion failure. CVE-2016-9444
Named mishandled some responses where covering RRSIG records are returned
without the requested data resulting in a assertion failure. CVE-2016-9147
Named incorrectly tried to cache TKEY records which could trigger an
assertion failure when there was a class mismatch. CVE-2016-9131
absolute name could trigger an infinite recursion bug in lwres[..]"; affects
users of lwresd and users with "lwres" enabled in their configuration).
Also has a couple of regression fixes. OK naddy@
were protected by different locks.
See http://fanf.livejournal.com/144615.html for an informative write-up
on the issue: "Even the Deathstation 9000 can't screw up the BIND 9.10.4
fix".
- Fixed a regression in resolver.c:possibly_mark() which caused
known-bogus servers to be queried anyway. [RT #41321]
- render_ecs errors were mishandled when printing out a OPT record
resulting in a assertion failure. (CVE-2015-8705) [RT #41397]
- Specific APL data could trigger a INSIST. (CVE-2015-8704) [RT #41396]
4260. [security] Insufficient testing when parsing a message allowed
records with an incorrect class to be be accepted,
triggering a REQUIRE failure when those records
were subsequently cached. (CVE-2015-8000) [RT #40987]
4253. [security] Address fetch context reference count handling error
on socket error. (CVE-2015-8461) [RT#40945]
and a possible crash with async zone loads. https://kb.isc.org/article/AA-01266
"If you are using RPZ in BIND 9.10 in a production environment, and
particularly if you have multiple policy zones, you should upgrade to
BIND 9.10.2-P1. Otherwise, this upgrade is not urgent."
On servers configured to perform DNSSEC validation using managed
trust anchors (i.e., keys configured explicitly via managed-keys, or
implicitly via dnssec-validation auto; or dnssec-lookaside auto;),
revoking a trust anchor and sending a new untrusted replacement could
cause named to crash with an assertion failure. This could occur in
the event of a botched key rollover, or potentially as a result of a
deliberate attack if the attacker was in position to monitor the
victim's DNS traffic. This flaw was discovered by Jan-Piet Mens, and
is disclosed in [CVE-2015-1349] [RT #38344] (**)
