CVE-2019-0726: An RCE Vulnerability in the Windows 10 DHCP Client

April 25, 2019 | Simon Zuckerbraun

In January of this year, Microsoft released a patch to correct a flaw in the DHCP Client service in Windows. An attacker could potentially get their code running on an affected system just by sending a specially crafted DHCP response. The root cause of this vulnerability was a malicious Domain Search option that could cause the DHCP Client service to allocate a zero-length heap buffer. Since the buffer has a length of zero, all writes to the buffer are out-of-bounds. This obviously piqued our curiosity about what other vulnerabilities could be found within the DHCP client.

The Vulnerability

After a bit of research, Saran Neti of Trend Micro Research discovered that there is another vulnerability that lurks nearby. In this new variation, the malicious Domain Search option begins with a zero-length domain name, encoded as the single byte \x00, indicating a length value of zero. A full example of such a malicious Domain Search option would be \x00\x07example\x03com\x00\x00. This encodes two domain strings, the first one having zero length, and the second one having the value The DHCP client code fails to handle this case correctly. When parsing the option data, it writes a comma character at offset 0xffffffff from the start of the output buffer, for an out-of-bounds write. The comma character is intended as a delimiter between specified domains.

A Look at the Code

Here’s a look at the offending source code:

The code fragment shown above copies one domain name from an input buffer to an output buffer, one “label” at a time (for example, www, microsoft and com would each be labels). It writes a period character to the output buffer as a delimiter after each label. Finally, when a label is found with a zero length, this indicates that the domain name is complete, and the code branches to 00007fff`b0793d6f.

The problem occurs at the last line shown above. After completely copying a domain name to the output buffer, the code intends to overwrite the final period with a comma, in preparation for copying additional domain names. Note that ecx is loaded with the value 1 (see 00007fff`b0793d6f-00007fff`b0793d72). At 00007fff`b0793d85, it subtracts 1 from the index that was found in [rsi]. The intention of subtracting 1 is to compute the index of the most recently-written byte in the output buffer, which ought to be the final period.

Unfortunately, the code fails to consider that there might be a domain name consisting of zero labels (that is, a domain name that is an empty string). In that case, no period was ever written to the buffer. Furthermore, if such a domain name appears at the very start of the source, then the index appearing in [rsi] will be zero. Subtracting 1 results in an integer underflow, yielding 0xffffffff. Hence at 00007fff`b0793d87, the comma character will be written to memory at offset 0xffffffff from the start of the buffer.

Demonstrating the Crash

To demonstrate this vulnerability, you’ll need to create an isolated network with a target Windows virtual machine (VM) and an attacker VM. You can pick your favorite flavor of Linux for the attacker VM. Install the ISC DHCP software on the attacker virtual machine and assign it an IP on the interface connected to the isolated network.

Start the ISC DHCP service with the following configuration:

Note that <interface> is the interface on the isolated network.

The target VM should be an installation of Windows 10 version 1803, without the March 2019 patches installed. We tested on version 17134.523 x64 (the January 2019 patch level).

We recommend starting the target Windows VM disconnected from the network. After starting the VM, enable page heap on svchost.exe using Global Flags. If you aren’t familiar with doing this, review this guidance from Microsoft on using page heap verification. Next, use Process Explorer to locate the process with dhcpcore.dll and kill it. This will spawn a new DHCP Client svchost.exe process with Page Heap enabled. Run WinDBG or your favorite debugger as Administrator and attach to the new DHCP process. Finally, connect the Windows VM to the network. When the target VM requests a new IP address via DHCP, the DHCP Client svchost.exe will crash:


Microsoft patched this particular vulnerability in March of this year and labelled it CVE-2019-0726. It’s interesting to see these bugs affect Windows 10 and Windows Server 2019 but not previous versions of the operating systems. This indicates the DHCP Client was rewritten, or at least substantially tweaked, in the latest Microsoft OSes. Of course, this potentially means further bugs may be found in the newer implementation of DHCP. If you come across any, you can always submit to them to our program. If you decide to submit to the ZDI, be sure to check out this blog post to get the most out of your submission.

Until then, you can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.