ISC Responds to Questions Raised About SRTT Algorithm Flaw

This week several of our customers have contacted us to inquire about our reaction to this article, entitled “Critical Vulnerability in BIND Software Puts DNS Protocol Security at Risk.”

ISC would like to clarify that we evaluated the risk from this issue in 2013 when it was disclosed to us, and do not judge it to be a “critical vulnerability” or feel that it “puts DNS protocol security at risk.” The article linked above is light on details, but you can follow this link to the original presentation from Woot ‘13 if you would like more background information on the SRTT algorithm flaw that allows an attacker to influence selection of a specific nameserver from the servers available in the NS record RRSET.

The authors of that paper responsibly reported the issue to ISC prior to their conference presentation and we evaluated it for its security threat potential at that time. We reached the conclusion that the technique described did not by itself constitute an exploitable defect in BIND security, but that it did have potential for use as an enhancement for other attacks. In order to explain the matter and make operators aware of it, we issued an Operational Notification for BIND admins and announced it on public mailing lists in August 2013.

Renewed interest in this matter has prompted us to re-examine the issue to see whether any new information has changed our opinion of the issue’s severity. At this time we still believe that the manipulation of server selection through exploitation of a flaw in the SRTT algorithm represents at best a supplement to other attack vectors. Nevertheless, ISC intends to correct the flaw in a future release of BIND but has not committed to a timetable for doing so.

If you are aware of an active exploit which uses this technique, or if you believe you are aware of an implication we may not have considered, we encourage you to share your concerns with our ISC Security Officers by e-mailing security-officer@isc.org. Please encrypt any communications containing sensitive security information using the Security Officer PGP key.

Thank you for the opportunity to clarify this matter.

Michael McNally, ISC Support Engineer