Operational Notification: A Vulnerability in the SRTT Algorithm affects BIND 9 Authoritative Server Selection
  • 29 Oct 2018
  • 3 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Operational Notification: A Vulnerability in the SRTT Algorithm affects BIND 9 Authoritative Server Selection

  • Dark
    Light
  • PDF

Article Summary

Summary

In 2013, ISC was made aware of a deficiency in the Smoothed Round Trip Time (SRTT) algorithm implemented in BIND 9 that could theoretically allow an attacker to artificially lower the SRTT value that a recursive resolver had associated with an authoritative server.

This could allow the attacker to influence the selection of a specific authoritative server from an NS resource record set with multiple values, determining which of multiple authoritative servers for a domain would be queried.

SRTT selection is not used by authoritative-only servers, but recursive-only or recursive-authoritative hybrid servers are vulnerable to being influenced in this manner.

Posting date: 13 August 2013

Program Impacted: BIND 9

Versions affected: All currently existing versions of BIND 9

Description

The Smoothed Round Trip Time (SRTT) algorithm is used by BIND to determine which authoritative server should be queried for a domain which has multiple listed servers in its NS record RRset.

The current implementation of the SRTT algorithm may be remotely exploited, allowing an attacker to influence the SRTT values assigned to the servers in an NS RRset. As a result, an attacker can influence which server (out of multiple possible servers) will receive queries for a specific domain.

By itself, this defect is considered to be of limited use as an attack vector, but it has security implications, as it may be used as a potential force magnifier when used in conjunction with other exploits. For example, if a single server from a multiple-server authoritative RRset is compromised, this technique would allow an attacker to ensure that queries were made to the compromised server, instead of whichever server would ordinarily have the lowest SRTT value.

ISC plans to address this deficiency by reimplementing the SRTT algorithm in future maintenance releases of the BIND 9 code.

Solution:

The deficiency in the SRTT algorithm is not considered an exploitable security vulnerability on its own. However, we are announcing it in this operational notification because:

  • An academic paper was presented to a security conference and we believe that explaining the context will help operators understand the implications for their DNS security.
  • The deficiency could hypothetically serve as a force multiplier for other attacks.

Future maintenance versions of BIND will reimplement the SRTT algorithm to address the deficiency, but for now the recommended strategy is to proceed with the awareness that the security of any service relying on DNS resolution for a specified domain is only as strong as the least secure server in the listed authoritative servers for that domain.

Note:

A May 2014 article (http://thehackernews.com/2014/05/critical-vulnerability-in-bind-software.html) prompted several users to contact us to ask about the current status of this issue. ISC disagreed with the article, which describes the SRTT issue as a critical DNS security flaw and compares it to the OpenSSL Heartbleed bug in severity.

Our position remained unchanged -- that the SRTT issue could be used to enhance the effectiveness of another attack but is not a significant threat by itself. ISC had plans to change the SRTT algorithm to prevent even this, but had not yet implemented those plans or committed to a timetable for doing so.

Readers wanting more background on the issue to judge for themselves can find the original conference presentation here: https://www.usenix.org/conference/woot13/workshop-program/presentation/hay.

Do you still have questions? Questions regarding this advisory should go to security-officer@isc.orgTo report a new issue, please encrypt your message using security-officer@isc.org's PGP key which can be found here: https://www.isc.org/downloads/software-support-policy/openpgp-key/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/community/report-bug/.

Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected.  (For current information on which versions are actively supported, please see https://www.isc.org/downloads/). 

ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: ISC Software Defect and Security Vulnerability Disclosure Policy.

This Knowledgebase article is the complete and official security advisory document.

Legal Disclaimer:

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.