Looking at the patch for this vulnerability, one can see that a new function was added, UShortAdd. Looking at this, I immediately thought that this might be a integer overflow vulnerability. Turns out I was right, but the actual bug is a little bit tricky to determine at first glance. This is cause when calculating the size for a heap allocation which is performed via a call to Dns_AllocZero, several functions first correctly convert the user’s input to an unsigned value, by using movzx to convert the attacker’s input, stored in the RCX register, into an unsigned integer after first adding 0x32 to its value. The result is then stored in RAX.

The problem comes in when it then goes ahead and tries to adjust this value further. In the case of the SigRecordCopy function, this is done by attempting to add 0x28 to AX. This is an issue as if AX is a large number, then adding 0x28 could cause it to overflow into a large negative number. In SigRecordCopy, this value is then incremented by 0x20 before then being used as the number of bytes to allocate on the process heap with Dns_AllocZero, meaning that the attacker can cause dnsrslvr.dll to allocate an undersized heap buffer, which is subsequently filled with data via a call to memcpy later on within the SigRecordCopy function.

This same logic was applied to a total of 6 different functions, which are listed below:

1. SigRecordCopy
   
2. NsecRecordCopy
   
3. KeyRecordCopy
   
4. OptRecordCopy
   
5. DhcidRecordCopy
   
6. Nsec3RecordCopy
   

As far as attacking these vulnerabilities go, there are a number of good and bad things to consider here. The first is that the overflow takes place on the process heap, which generally speaking is harder to exploit than a normal stack overflow, however articles like https://blog.rapid7.com/2019/06/12/heap-overflow-exploitation-on-windows-10-explained/ have shown that it is possible to gain reliable control over the process heap assuming certain requirements are met. The main issue in exploiting this likely would be the need to find a separate information leak to exploit more recent machines and bypass the DEP + ASLR protections that will be enabled on them.

On the other hand the good news is that some of these affected functions are very short so it is unlikely that an attacker would have issues with stray instructions messing up their exploit should they manage to find a good information leak. Also since this is a local privilege escalation, then since the attacker would have local access to the victim’s machine, they would likely be able to have more opportunities to find DEP/ASLR bypasses that might not otherwise be exploitable remotely.

Finally given the nature of this bug, it seems likely that an attacker would have to set up some sort of malicious DNS server, and then they would have to query it. The result would then be placed in the DNS resolver cache, and when the same query is made again, the corresponding record copying function would be called within dnsrslvr.dll, which would then cause the heap overflow. This is just my initial guess though based on the expected behavior of dnsrslvr.dll though.