Important Update: This is now supposedly being exploited in the wild by Chinese state actors according to this NSA announcement: https://media.defense.gov/2020/Oct/20/2002519884/-1/-1/0/CSA_CHINESE_EXPLOIT_VULNERABILITIES_UOO179811.PDF

Update: Checkpoint has since released their blog post at https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ with much more details on this vulnerability than when I originally wrote this. I’ll update a few statements here but readers are encouraged to read the paper for more details.

On July 14th, 2020, Microsoft released CVE-2020-1350, a critical DNS server remote code execution vulnerability that can result in Domain compromise and which is listed as a 10.0 CVE rating. Microsoft also described this vulnerability as wormable and recommended the following mitigation:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
  DWORD = TcpReceivePacketSize 
  Value = 0xFF00

This is rather odd to me. 0xFF00 looks like a potential mitigation against a integer overflow, as its possible the vulnerability stems from any packets being over 0xFFFF causing an integer overflow in memory, resulting in the allocation of a very small amount of memory to hold a very large buffer. At the very least, the fact that the recommended mitigation forcibly controls the max size of the packet that can be received suggests that this is a buffer overflow of some sort. Given the dynamic nature of DNS and the fact that it has to handle multiple requests at once, my guess is that its a heap buffer overflow.

Now that CheckPoint’s blog post is public one can confirm that this is in fact a integer overflow leading to a heap buffer overflow within the SigWireRead function of dns.exe, the server component of Microsoft’s DNS implementation. When the DNS server receives a SIG query response, that, when decompressed, incremented by 0x14, and added to the result of an earlier Name_PacketNameToCountNameEx call, is greater than 0xFFFF, will result in integer overflow, resulting in the following RR_AllocateEx call allocating too small of a heap buffer for the resource record, and a heap buffer overflow occurring when memcpy is called to copy the SIG query response into the overly small heap buffer that RR_AllocateEx allocated.

A very important point to note here is that whilst there is a RCE potential here by smuggling DNS requests over HTTP, it seems that CheckPoint has noted that only some browsers, notably Microsoft Edge and Internet Explorer, actually support sending HTTP requests to port 53, so whilst their video at https://youtu.be/PUlMmhD5it8 is certainly pretty cool, its important to note that with Google Chrome taking up over 65% of the browser market share according to https://gs.statcounter.com/browser-market-share as of July 2020, and IE and Edge accounting for a combined total of roughly 4% of all browsers, its pretty unlikely that most organizations will be affected by the HTTP smuggling attack vector unless users are forced to use IE/Edge in their networks for some reason (such as support for legacy apps).

Edit: @cblack-r7 Also pointed out to me that looking at https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability they mention this line “After the workaround is implemented, a Windows DNS server will be unable to resolve DNS names for its clients when the DNS response from the upstream server is larger than 65280 bytes.” He noticed that the terminology “upstream server” could mean that the malicious overly large DNS response has to come from an upstream resolver, which could complicate this vulnerability a little bit. This is also something that @busterb’s assessment seems to reflect concern about and is something that the CheckPoint blog doesn’t really address from what I’ve seen (though feel free to correct me if I am wrong here)

It should be noted that this vulnerability only affects Microsoft’s DNS implementation, however it goes way back all the way to Windows Server 2008. I wouldn’t be surprised if this also potentially affected Windows Server 2003 as well though, given how these types of vulns tend to be rather systemic, but I could be wrong there.

Another important point to note is that on Windows the DNS service runs as SYSTEM, so this will essentially be a remote SYSTEM level exploit for any attackers, which is pretty powerful. Unfortunately there is a limitation that if this is a remote RCE on the heap, the attacker will most likely have to deal with a lot of the new heap related mitigations introduced starting with Windows 8 and which were greatly improved with Windows 10. So this likely means that Windows Server 2008 and Windows Server 2008 R2 will be easy to develop an exploit for, but more recent servers like Windows Server 2019 may see a noticeable lag in exploit development time whilst exploit developers work their way around these mitigations. This can be seen in past heap overflow exploits where the Windows 7/Windows Server 2008 exploit came out very quickly but in some cases it took several months or even a year for the Windows 10/Server 2019 exploit to come out.

It should be noted that whilst this vulnerability has not been used in active attacks according to Microsoft, I’d safely place money on seeing this vulnerability get weaponized very quickly.

Given the need to include a corrupted response from a recursive DNS server in the chain, this may be difficult to exploit in practice, at least with a properly configured DNS server that doesn’t allow recursive queries from untrusted sources.

This vuln seems like it needs a hat trick to execute, when there might be easier ways to get DA in a network, but after looking at some analysis by others on this, it seems there could be some creative solutions. I’m changing my mind in that there may be some form of attack on this soon, even if it’s just leveraging the DoS attack, such as this is a crash PoC from maxpl0it:

https://twitter.com/maxpl0it/status/1283537179365564417
https://twitter.com/maxpl0it/status/1283471692006920193

Here are some ruminations on alternate vectors outside of just directly making queries:
https://twitter.com/bmenrigh/status/1283189603873075201

Basically all the info is here for someone to try to attempt a mass DoS attempt at least in conjunction with some sort of side-channel attack on domain-joined clients. So this may become easier to weaponize for crashing domain controllers, but I still posit a reliable RCE will be difficult.

I’m going to quote @hrbrmstr here: Since the registry config workaround doesn’t require a system restart, it seems like this is going to be a niche exploitation issue for organizations that haven’t config’d or patched their way to safety.

Still haven’t seen PoC past the DoS from maxpl0it (which is a very good Twitter username, unrelatedly) that surfaced quickly after the vuln details were published. Anecdotally, a few other researchers have mused that this probably isn’t the ripest or most valuable target for exploitation (famous last words, eh?).