FAQ for CVE-4854 – BIND Vulnerability

In order to help our customers with their DNS-related questions, we wrote this blog post regarding the recently announced BIND vulnerability, CVE-4854.

What happened?

ISC announced a critical vulnerability in the popular BIND DNS software. This might affect you.  BIND servers configured either as caching or authoritative are vulnerable.

A patch was made available that fixes the issue on the standard BIND server.

I have Secure64 DNS Cache/Authority/Signer, Am I vulnerable?

No, Secure64 does not share any code with BIND. To be 100% sure we have reverse engineered the patch in our lab and created an exploit that we tested against our product. We have verified that our products are not vulnerable.

Commercial vendors of BIND appliances such as Infoblox, Bluecat and F5 appear to be vulnerable. Please contact them for information on how to patch your system.

How critical is this vulnerability?

It is very critical as it is remotely exploitable.  That means that anybody can send a specially crafted query to crash a BIND server. It is also easy to spoof the sender so that it is impossible to trace who sent the packet.

From what we understand in our lab, the BIND vulnerability can be exploited to crash the BIND server. But we can’t see a way to get the BIND server to run arbitrary code by exploiting this bug.

I have BIND servers in my setup. What do I need to do?

If your BIND servers are receiving queries from the internet or your internal network, then you need to contact ISC or your appliance vendor for a patch and apply it immediately.  There is no known workaround.

If your BIND servers are hidden masters and do not receive any queries other than zone transfers from your slaves, then you might want to consider waiting until the next scheduled service window before performing the upgrade.

Are there any exploits in the wild?

According to the ISC website, the issues have been reported by several customers, indicating exploits in the wild. The expectation is that more hackers will start to take advantage of this vulnerability as it is pretty easy to figure out what packet to send.

If your BIND server crashed and left the following message in your syslog, then you are vulnerable:

REQUIRE(region->length >=  4 ) failed”

Can I block this with my firewall/IPS/DDoS equipment?

The offending packet is a regular query so it is not possible to block a certain port or Ip-address. What is needed is deeper inspection into the DNS packet itself. Some firewalls and IPS systems are capable of such deeper inspection and can theoretically protect against the attack if they are configured correctly.