In late July the Internet Systems Consortium (ISC) released security updates to resolve critical denial of service (denial of service, defined) CVEs (CVE, defined) that exist in their BIND DNS software.
The first flaw is due to an error in handling TKEY queries (transaction key: the data structure that holds information in a standardized format for exchange between DNS servers). A single specifically crafted packet sent to BIND will cause it to trigger a REQUIRE assertion failure which will cause BIND to exit. Assert functions are generally used in software code to trigger a program to halt when certain conditions occur.
The remaining flaw patched by ISC is due to an error in how BIND parses (analyses data in a structured manner in order to create meaning from it) data when performing DNSSEC validation for data contained within a specifically crafted DNS zone (the area in which a DNS server has authority for (see also “Aside” below)). This will result in the BIND software exiting resulting in a denial of service condition (denial of service, defined). While this issue has workarounds, they are not recommended actions since they have drawbacks, instead installing the updates mentioned in this security advisory is the recommended resolution.
Why Are These Issues Considered Critical?
These issues were assigned such a severe criticality rating due to their impact on the DNS name resolution software, namely that the software stops functioning. In addition, these issues are considered easy to exploit. For any device that uses your server for DNS services, those devices will no longer be able to access websites, other intranet resources or use email. If this issue is exploited on a wider scale, large parts of the internet would no longer be able to function correctly until those DNS servers were returned to service.
In addition, according to two separate sources exploits for this issue are already being seen in the wild. The availability of some popular websites has been affected. Since your website can be a large contributor to your revenue it is in your interest to address this issue.
How Can I Protect Myself From These Issues?
If you use BIND (it is included with Linux distributions e.g. Ubuntu, Redhat etc.) to provide any DNS services within your company or you know anybody who may be affected by this issue, please follow the advice in ISC’s security advisories to install the necessary updates to resolve these issues:
What is a DNS zone?
A companies domain e.g. example.com can be split for organizational/administrative reasons into departments e.g. accounting.example.com , admin.example.com etc. Each of these divisions/splits is then referred to as a subdomain zone within the root domain (example.com). Depending on the size of an organization, for performance reasons multiple DNS servers may be assigned to provide DNS services for specific subdomains e.g. DNS server 1 provides DNS for Accounting and Admin while DNS server 2 is responsible for Production and Support.
Thus each server is responsible for different zones. These servers are authoritative for those zones (since those servers contain the hostname (the name of a device within a domain or subdomain) to IP address translation. This is similar to a person looking up a person’s name in a phone book to find their telephone number, DNS provides this service to enable computers to communicate with one another.
For an example of how DNS is used when web browsing, see the section titled “Why Does An Attacker Want To Change My Router’s DNS Settings” within a previous blog post.
What is DNSSEC?
This is set of extensions to the original DNS standard that provides extra security such as origin authentication (where the DNS translation data came from). This is to prevent spoofing (where an invalid hostname to IP address translation is provided by another DNS server (potentially controlled by an attacker)) and DNS cache poisoning (where spoofed values are stored alongside legitimate values within a DNS server, such values will be provided to DNS queries taking devices to unexpected locations).
DNSSEC uses a Public Key Infrastructure (PKI) as well as digital signatures to allow the verification of authenticity of the DNS data received. The PKI allows the management of encryption keys and digital certificates (used in digital signatures) to maintain a trusted environment. The digital signatures are a means of verifying that the DNS information received has not been altered and has come from a known and trusted source. The digital certificates included with the signatures are issued/vouched for by certification authorities (CA, defined) e.g. Thawte, DigiCert and VeriSign etc.