The Dell – Microsoft issue

Why Vendors are both the reason for the vulnerability, and lack of thorough treatment

By this time, you are probably wondering why we are telling you an old story, as this CVE is more than a Year old, and has received the attention of all major vendors which relate to it…right?

Dell has revoked the certificate from the driver, and also rolled out a patch, so …all good?

So… it’s a bit more complicated than that.

BYOVD- Bring Your Own Vulnerable Driver is still a thing!

Even if the driver is not pre-installed, all it takes is privileges to install a driver to make a machine vulnerable

In the following year, when performing Red Team engagements with customers around the world, we have found that this driver is mostly not pre-installed anymore, but given the opportunity to bring our own driver, no mechanism has truly implemented a solution for preventing installation of the driver.

We would have expected either of the parties - Security vendors / Microsoft to take extensive measures to assure that such CVE cannot exist on a system, also due to the fact that it’s simply a driver, which contains a specific digital signature (already expired btw), and that has a specific hash or a symbolic link that it creates, but with that being said, we have installed the driver time after time without any interruption!

Well, as for the answer to why we are not yet in an era in which this driver cannot be installed, is the previously mentioned fact about this driver.

It is a DELL driver, and even to this day a year later, millions of computer units may still contain and run this driver, and completely removing any ability for this driver to exist, will most likely, allegedly, hurt the users of DELL, and as such, its business.

Now this is not fine, but it is what it is. When we step out of the boots of Cyber Security and into the simple user’s boots, we would have been pissed as well if our computer would suddenly load into recovery mode for an issue that “most likely” would not concern us.

With that being said, we DO expect highly valued vendors for Endpoint Security to mitigate a simple file in a way which prevents users from interacting with the kernel directly, and actions to completely seal this have not been made.

Now if what you are thinking, is that no vendor should spend this much amount of money and R&D efforts for one driver, we think differently, and that is due to hundreds of drivers which are discovered every day which expose the same abilities, where the only difference is the IOCTL code, and the buffer structure.

As such, we would have expected to meet a fair opposition while testing new code against EDRs, but the opposition did not occur.

Last updated