Today we released MS11-058 to address two vulnerabilities in the Microsoft DNS Service. One of the two issues, CVE-2011-1966, could potentially allow an attacker who successfully exploited the vulnerability to run arbitrary code on Windows Server 2008 and Windows Server 2008 R2 DNS servers having a particular DNS configuration. We’d like to share more detail in this blog post and help you make a risk decision for your environment.
Affected DNS configuration
This vulnerability affects DNS servers that allow attackers to issue lookup requests for another domain name in a way that would cause the DNS server to request the answer from a malicious DNS server. Specifically, if an attacker can cause a DNS server to request a DNS NAPTR resource record from a malicious DNS server, the attacker could potentially trigger the vulnerability described by CVE-2011-1966 on the DNS server of which the attacker is making the request.
One common affected configuration is a caching or relay DNS server on a corporate network where a malicious user is lurking. Less likely to be affected are authoritative DNS servers hosting zones exposed to the Internet, where recursion is often disabled. For example, anyone on the Internet can connect to the microsoft.com authoritative DNS server, but that server will not relay requests to a malicious DNS server.
More information about the DNS protocol, DNS recursion and forwarding:
Unlikely to be exploited for code execution
An affected system receiving a malicious NAPTR resource record from a malicious DNS server will result in heap memory corruption. For this reason, the security bulletin describes this issue as having the potential for remote code execution. However, due to the nature of this vulnerability, it is far more likely to result in a denial-of-service condition where the DNS service terminates unexpectedly and less likely to result in remote code execution.
This is due to the type of vulnerability and the platform mitigations provided by Windows Server 2008. The issue is a sign-extension vulnerability where a small negative number is expanded to a larger type without proper checks. Later, this large negative number is used as a memcpy count to populate a heap buffer. The copy length will always be at least 0x80000000 bytes long so the copy operation itself will likely fail in the absence of 2+ GB of memory available to be copied. Even if an attacker is able to successfully populate memory for the copy to succeed and massage the heap to gain control of the process, the platform mitigations of ASLR, DEP, and the heap metadata protection must still be overcome before malicious code could be run. And, finally, an attacker has only three opportunities to exploit a particular DNS server - the service control manager will no longer restart it after it crashes three times. While code execution is theoretically possible, we think a denial-of-service is most likely. Hence, we have rated the likelihood of exploit code for remote code execution appearing in the next 30 days as “3 – Functioning Exploit Code Unlikely”.
More detail about the attack vector
Due to the distributed nature of the DNS protocol, DNS servers configured to resolve names on behalf of client and applications usually support recursion (unless explicitly disabled by Admin), allowing them to talk and exchange information with other DNS Servers. The vulnerability exists in the way a Microsoft DNS Server parses NAPTR records from a remote DNS server. Here is an example, assuming the attacker controls the contoso.com DNS server and has configured it to return malicious NAPTR record data:
The victim DNS server in this case could be an unpatched Microsoft DNS Server with recursion / forwarding enabled. The attacker knows that the victim server will communicate with the contoso.com DNS Server to fetch the DNS NAPTR record requested by the client. The attacker’s malicious DNS Server then responds with the malformed NAPTR data which triggers a crash on the victim DNS Server. The victim server crashes due to the CVE-2011-1966 vulnerability while attempting to parse the malicious NAPTR record content. The crash happens only for a particular set of data for NAPTR records.
Answers to common questions
Q: I don’t host NAPTR record; is this patch applicable to my deployment?
A: Yes. As indicated above, the problem lies in the code that parses the malformed data while receiving it from other sources, not while hosting it. If your DNS Servers have recursion enabled and allows potential attackers to issue requests, this patch should be applied.
Q: I host only authoritative zones on my DNS server and have disabled recursion. Is it vulnerable?
A: This configuration is technically not vulnerable. However, due to the dynamic nature of networks, we recommend that you patch all DNS servers to prevent future configuration changes from opening attack surface.
Q: Are enterprise deployments vulnerable to this attack?
A: Enterprise networks that use a web proxy and do not allow enterprise DNS server to resolve Internet names would certainly be at reduced risk. One attack vector remaining in that case is that of an attacker with minor access rights on an enterprise network bringing up a malicious DNS server. However, they will likely face difficulty in coercing the real enterprise DNS server to direct queries to it without some level of administrative privilege.
Thanks Bruce Dang, Saaransh Bagga, Shreyas Behera, Jeremy Tinder, Nicolas Guigo, Matt Miller, and Jeff Westhead for contributing to this blog post.
- MSRC Engineering