The bind package shipped in Red Hat Enterprise Linux 7 from version 9.9.4-65 is vulnerable to an issue when the debug log level is 10 or higher, allowing for remote attackers to cause a crash via crafted queries. This issue is a regression introduced by the backport of the "negative trust anchors" patch included from version 9.9.4-65.
This flaw appears to be exploitable only when debug logging is enabled and set to at least a level of 10. As this configuration should be rare in production instances of bind, it is unlikely that most servers will be exploitable. The debug level of the bind server can be checked via the rndc status command, which will return the current trace level as "debug level". A value of 10 or above would most likely make this flaw exploitable.
Ensure that debug logging is disabled and set to 0. This can be verified on the Bind server by the rndc status command.
Callflow starts here in resolver.c:
dns_message_logfmtpacket(message, "received packet:\n",
and appears to potentially end with an assert inside of isc_buffer_putstr.
if ((ctx->style.flags & DNS_STYLEFLAG_COMMENTDATA) != 0)
We can get some of these messages via -d 10 passed to named:
named -d 10 -f -g 2> >(grep "received packet:" -A 15)
On a default install of bind, the above command should show you some of these packet dumps (you may have to change permissions of /var/named to avoid some permissions errors). Dropping the debug level down just one level to 9 disables this specific print.
Thus, most likely exploitable, but only on debug configs. I suspect very few bind instances are running with debug logging.
Looks like this flaw is impacting more than I thought. Going to re-analyze and try to determine if this is exploitable somehow with less than debug 10 logs enabled or if lots of people really like verbose bind logs.
Unembargoed due to public info being available.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2019:0194 https://access.redhat.com/errata/RHSA-2019:0194