Updates

We received a lot of feedback and comments to this issue. Here a quick summary:

• This only affects caching/resolving name servers. Authoritative name servers are not affected as they only send responses and will never receive responses (only queries).
• The patch will impact your servers performance. Test carefully before patching a very busy server. isc.org mentions 10,000 querries/sec as a problem.
• For BIND users, there is a non-IETF approved workaround to implement DNSSEC without full PKI. See "DNSSEC Look-aside Validation" for details.
• The overall issue has been known for a long time, and is a fundamental problem with the way DNS currently works. However, full details about what makes this so special will be revealed at Blackhat. There may be more to it. For example think about better tools to exploit it and exploits see in the wild.
• Please test carefully. At least Zonealarm seems to have problems with the respective Microsoft patch. Other firewalls may be "surprised" too by your DNS server all for sudden changing ports a lot.
• Don't forget embedded devices. In particular BIND is frequently used as a DNS server on firewalls and routers. If you don't need it: disable it.
• Stay in touch with your vendors. Please let them know if you experience any issues.
• Dan Kaminski's site: http://www.doxpara.com/ (includes a self-test)

Today, Microsoft was just one vendor releasing a patch for its DNS server. The Internet Systems Consortium (www.isc.org) published a very similar patch for its own DNS server, BIND.

Many other DNS servers are derived either form BIND or Microsoft's DNS server. Expect more similar announcements over the next couple days.

The Problem

The root cause is a fundamental, well known, weakness in the DNS protocol. DNS uses UDP, a stateless protocol. A DNS server will send a request in a single UDP packet, then wait for a response to come back. In order to match request and response, a number of parameters are checked:

• who sent the response? Was it the DNS server we sent the request to?
• for this particular response, do we have an outstanding request?
• each request uses a unique and random query ID. The response has to use the same query ID.
• The response has to be sent to the same port from which the request was sent.

Only if all this matches, the response is accepted. The first valid response wins. If an attacker is able to guess the query id and the source port, the attacker is able to send a fake response, which will be cached by the DNS server.

How likely is it to "guess" the query id and the source port? One would think, its not that easy. The query ID is 16 bits long, allowing for 65536 options. The source port could be anything above 1024 which again would allow for another 64512 options. It is easy to guess which DNS server is expected to reply, as it has to be a valid DNS server for the respective domain. A reasonable DNS server should respond in less then a second, allowing for about 1 second to send the spoofed response.

At least for BIND, the source port only changes whenever you restart it. Once restarted it keeps using the same source port.

Ideally, one would think that it would take millions of packets per second to successfully spoof the response. However, the problem is in the details. A DNS server can not use any port to source the query. It may not use a port commonly used by outbound connections, or a port reserved by a server. This is an issue attacked by today's patches. As of today, DNS servers used a rather small set of ports to source requests. This is the actual new finding. The patch will increase the pool of source ports available to DNS queries. To make things worse: the real DNS server may be silenced using DDoS attacks.

Over the past few months, we had a couple patches (again both for Microsoft as well as for BIND) addressing the randomness of the query ID.

How bad is it?

If you run a caching DNS server, patch it soon. I wouldn't say "today, while ignoring sane patch management". But check with your vendor and follow their guidance. The world is not going to end today. It will in fact end in 2 1/2 years from today (different story ;-) ). But this is something you have to fix soon. Right now, the US-CERT advisory lists a handful of vulnerable products and quite a few "unknowns".

Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works).

One thing to carefully test is your firewall. We already heard about issues with Zonealarm and MS08-038. However, it is possible that other firewalls will think that something is wrong if your DNS server all for sudden keeps jumping ports.

Where can I find out more?

CERT: www.kb.cert.org/vuls/id/800113
Microsoft: http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx
Internet Software Consortium (BIND): http://www.isc.org/sw/bind/bind-security.php
Dan Kaminski on Martin McKeay's Podcast: http://media.libsyn.com/media/mckeay/nsp-070808-ep111.mp3

DNSSEC resources:

DNSSEC Overview:  http://www.dnssec.org
DNSSEC Deployment Initiative:  http://www.dnssec-deployment.org
DNSSEC HowTo:  http://www.nlnetlabs.nl/dnssec_howto 

-----

UPDATE:

 The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable.
 "Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation"

isc.org warns busy DNS resovlers could be impacted by their patch so they recommend the beta release version.

"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."

Johannes B. Ullrich, Ph.D.
SANS Technology Institute - http://www.sans.edu