June 21, 2024
In our prior blog post we discussed how the promotion of BYOVD protection is disingenuous. In this article, we will dig deeper into the blurry lines between “vulnerable” and “not vulnerable” when it comes to Windows drivers.
The simplest example of a vulnerable Windows driver is a driver that exposes to unprivileged users a device Input and Output Control (IOCTL) that performs a privileged action.
When it comes to specifying access to what a device driver can do, there are three primary routes that can be taken: 1. Set per-IOCTL RequiredAccess values that correspond to permissions granted at a device level. 1. Set device-level permissions that restrict which Windows users/groups can even open the device. 1. Just go with the default ACLs.
Let’s look at these possible strategies.
Microsoft outlines setting RequiredAccess parameters on the per-IOCTL level, and also warns:
Note
Before specifying FILE_ANY_ACCESS for a new IOCTL code, you must be absolutely certain that allowing unrestricted access to your device does not create a possible path for malicious users to compromise the system.
Using this strategy requires properly configuring two levels of access control:
RequiredAccess value that captures the potential harm that may occur as the result of a user calling the IOCTL. For example, an IOCTL that is harmless may advertise that it can be called with a FILE_ANY_ACCESS RequiredAccess value. But other IOCTLs that may influence or leak information about the Windows kernel should be restricted by requiring FILE_WRITE_DATA or FILE_READ_DATA, respectively.Everyone Windows group does not have Write Data or Read Data permissions to the device, then users in this group will not be able to call IOCTLs that require FILE_WRITE_DATA or FILE_READ_DATA, respectively.Presumably due to the complexity of the above strategy, many device driver authors appear to handle device driver permissions at the device level. For example, if a device driver specifies a device permission that does not grant the Everyone group the ability to open the device, then the device cannot be opened by users that are simply in the Everyone Windows group. This is one strategy to designate a device as only usable by admin privileged users or by the Windows system itself.
Unless the driver developer uses a development framework that provides default secure ACLs, such as KMDF, a Windows driver will by default expose its capabilities to Everyone on the system. Such a device driver that has an IOCTL that can perform a privileged operation will expose the system to privilege escalation by way of the driver.
Regarding KMDF and ACLs, the KMDF documentation (.doc format) explicitly specifies:
Unless the driver specifies otherwise, KMDF provides access control lists (ACLs) that require Administrator privileges for access to any exposed driver constructs, such as names, device IDs, WMI management interfaces, and so forth.
The Dell dbutil_2_3.sys driver is known to be vulnerable (CVE-2021-21551) as it exposes to unprivileged users IOCTLs to read and write kernel memory. We can confirm this by using WinObjEx64 to view the relevant device security properties.
We can see that the Everyone group can read from and write to the device.
Dell addressed CVE-2021-21551 by changing device permissions to SYSTEM or accounts in the Administrators group.
Like the Dell dbutil vulnerable driver, the vulnerable mhyprot driver exposes a number of dangerous kernel IOCTLs to non-admin users. We can confirm this by using Sysinternals WinObj to view the device.
On a system with this driver present, any user in the Everyone group can read and write to the mhyprot2 device. As such, the IOCTLs exposed by the device driver can be used by non-admin users of the system. Among the exposed IOCTLs include the ability to call ZwTerminateProcess, which can be used to terminate a process on a Windows system, even if it’s a Protected Process Light (PPL) process, as many anti-virus and EDR processes are. It also exposes the ability to read and write kernel memory, which can be used to accomplish just about anything that an attacker would want to do on a Windows system.
The fix for CVE-2020-36603 is incorporated into the mhyprot3.sys driver, which doesn’t even allow an unprivileged user to open the device. As such, we can’t even view the “Security” tab of the device in WinObj:
Observing what is on the Microsoft recommended driver block rules list and what is not on the list is a straightforward way to understand what makes a driver vulnerable or not. This can help to capture what Microsoft considers to be a vulnerable driver in practice today.
If we look at the language used by the Microsoft Vulnerable and Malicious Driver Reporting Center, a different picture is painted. According to this resource, any of the following attributes would be sufficient to consider a driver to be vulnerable:
Note that this language indicates that the exposure of the capability from kernel mode to user mode is all that is necessary to be considered a security vulnerability. There is no exception for admin-privileged user mode.
The two example drivers above have escaped being included in the Microsoft recommended driver block rules list by way of requiring administrative privileges to use the provided device. If simply enforcing the requirement of administrative privileges is enough to get removed from the Microsoft recommended driver block rules list, what is the motivation for a vendor to redesign their driver in a way that avoids using the above three capabilities? Beyond this, the Microsoft Vulnerable and Malicious Driver Reporting Center wording clearly indicates that dangerous behaviors is some opaque list of behaviors including (but not limited to) the above three behaviors.
Remember that Microsoft also clearly states that there is no security boundary between Administrator to Kernel. If Microsoft themselves will not service an issue that allows an Administrator user to do dangerous things with the Windows kernel, then why should other vendors be held to a higher bar?
The answer is that they are not being held to a higher bar. In the current Windows world, if a device driver exposes sensitive kernel operations to non-admin users, simply changing the driver to require admin privileges is enough to make it fall into the “not vulnerable” camp.
As mentioned in our prior blog post, advertising BYOVD protection is disingenuous, due to the requirement that an attacker already have admin privileges. If BYOVD protection is a thing that Microsoft aims to provide, then it is necessary to explain what it actually means for a driver to be vulnerable to fulfill the “V” in BYOVD.
The Microsoft Vulnerable and Malicious Driver Reporting Center wording appears to be an ideology for what might be actually enforced with future versions of Windows. The MSRC servicing criteria for Windows wording, on the other hand, can probably be considered a reflection of the real world today.
In the real world today, a driver is considered to be vulnerable if it exposes powerful kernel-level primitives to non-admin users. With this knowledge, consider the concept of what BYOVD protection means. The “V” in BYOVD means that a non-admin user can leverage the driver’s capabilities. The “BYOD” in BYOVD means that the attacker already has admin privileges.
It's possible that in some point in the future, the concept of what makes a Windows driver vulnerable may change. Only after this change occurs, advertising BYOVD protection may be possible. In the current Windows world that we live in, BYOVD protection simply makes no sense.