weakness in the DNS
protocol may enable the poisoning of caching
recurive resolvers with spoofed data. DNSSEC
is the only full solution.
New versions of BIND
provide increased resilience to the attack.
Posting date: 08 Jul 2008
8 (all versions) 9.0 (all versions) 9.1 (all
versions) 9.2 (all versions) 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4 9.4.0,
9.4.1, 9.4.2 9.5.0a1, 9.5.0a2, 9.5.0a3, 9.5.0a4, 9.5.0a5, 9.5.0a6,
Thanks to recent work by Dan Kaminsky of
IOActive, ISC has become aware of a potential attack exploiting
weaknesses in the DNS protocol itself. (Full details of the
vulnerability will be explained by Kaminsky at the Black Hat conference
on August 7th.) The weakness is inherent to the DNS protocol and not
specific to any single implementation. The DNS protocol uses the Query
ID field to match incoming responses to previously sent queries. The
Query ID field is only 16 bits, which makes it an easy target to exploit
in the particular spoofing scenario described by Kaminsky.
None known at this time.
IF YOU ARE RUNNING BIND AS A CACHING RESOLVER YOU NEED TO TAKE ACTION.
DNSSEC is the only definitive solution for this issue.
Understanding that immediate DNSSEC deployment is not a realistic
expectation, ISC is releasing patched versions of BIND that improve its
resilience against this attack. The method used makes it harder to spoof
answers to a resolver by expanding the range of UDP ports from which
queries are sent, thereby increasing the variability of parameters in
YOU ARE ADVISED TO INSTALL EITHER THE MOST CURRENT SECURITY PATCHES,
STAYING WITHIN YOUR MAJOR VERSION (currently 9.5.0-P2, 9.5.0-P2-W1,
9.4.2, 9.4.2-P2-W1, 9.3.5-P2, or 9.3.5-P2-W1 ) OR ELSE THE LATEST BETA
RELEASES (9.5.1b1, 9.4.3b2) IMMEDIATELY.
The patches will have a noticeable impact on the performance of BIND
caching resolvers with query rates at or above 10,000 queries per
second. The beta releases include optimized code that will reduce the
impact in performance to non-significant levels.
DNS administrators who operate these servers behind port-restricted
firewalls are encouraged to review their firewall policies to allow this
protocol-compliant behavior. Restricting the possible use of various
UDP ports, for instance at the firewalls, in outgoing queries and the
corresponding replies will result in decreased security for the DNS
Again, DNSSEC is the definitive solution to this type of attack. ISC
strongly encourages DNS administrators to deploy DNSSEC as soon as
possible to fully address this problem. DNS domain owners that want
their data to be protected against spoofing to the end-user must sign
their zones. ISP and Enterprise DNS administrators who provide caching
recursive name servers to their users should enable DNSSEC validation.
DNSSEC Lookaside Validation (DLV), offered by ISC and others, is another DNSSEC deployment option.
Additional Assistance Available from ISC:
BIND 9 software support: https://isc.org/services/support
Managed caching resolvers: Through September 30, 2008, ISC support
customers have the option of forwarding their recursive servers'
queries to caching resolvers deployed on ISC's SNS production network
while the required software upgrades are performed on their own
networks. For additional information on this option, please open a
ticket in your support queue with the subject line including "forwarder
ISC DLV: https://isc.org/solutions/dlv
Also see ISC's page DNSSEC and BIND
See our BIND Security Matrix for a complete listing of Security Vulnerabilities and versions affected.
If you'd like more information on our Forum or product support please visit www.isc.org/support.
Do you still have questions? Questions regarding this advisory should go to email@example.com
Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected.
ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy
This Knowledge Base article https://kb.isc.org/article/AA-00924 is the complete and official security advisory document.
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.
© 2001-2016 Internet Systems ConsortiumPlease help us to improve the content of our knowledge base by letting us know below how we can improve this article. If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback. For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.