Windows Driver-Signing Doesn’t Work
Having Microsoft verify third-party drivers with a digital signature, so that Windows will block the loading of unsigned drivers, seemed like a good idea when it came in with Windows Vista. Enforcing quality control would remove a big source of crashes, as well as security loopholes. But it seems the execution falls somewhat short <https://arstechnica.com/information-technology/2022/10/no-fix-in-sight-for-mile-wide-loophole-plaguing-a-key-windows-defense-for-years/>. The system for revoking signatures for old, obsolete drivers that are discovered to have security vulnerabilities in them doesn’t seem to work very well, allowing miscreants to exploit this old code to gain control of Windows systems. This has been dubbed a “Bring Your Own Vulnerable Device/Driver” (BYOVD) attack. Microsoft’s own Vice President of “OS Security and Enterprise” continues to claim that “Windows has everything you need to block” buggy signed drivers. Yet the article’s author was unable to get the mechanism to work. And Microsoft itself appeared to have no interest in helping to fix that. It seems to me, one thing missing from the mechanism is a time limit on signature validity. By contrast, when you get SSL/TLS certs for your website, they are only valid for some fixed interval (e.g. a year for certs from traditional certificate authorities, 90 days for ones from Let’s Encrypt). This means that clients using such certificates do not need to maintain an ever-growing list of revoked ones to check against, since ones that are past their expiry date can be rejected anyway. If the cert for a Windows driver has expired, but the driver itself is still valid, Microsoft should be able to simply renew the certificate. But I guess if Microsoft’s servers are struggling just to distribute certificate revocations, having to push out renewals as well will likely just make things worse.
On Thu, 6 Oct 2022 14:36:36 +1300, I wrote:
Having Microsoft verify third-party drivers with a digital signature, so that Windows will block the loading of unsigned drivers, seemed like a good idea when it came in with Windows Vista. Enforcing quality control would remove a big source of crashes, as well as security loopholes.
But it seems the execution falls somewhat short <https://arstechnica.com/information-technology/2022/10/no-fix-in-sight-for-mile-wide-loophole-plaguing-a-key-windows-defense-for-years/>.
Followup article from the same author <https://arstechnica.com/information-technology/2022/10/how-a-microsoft-blunder-opened-millions-of-pcs-to-potent-malware-attacks/>. As an example, this linked description <https://www.trendmicro.com/en_us/research/22/h/ransomware-actor-abuses-genshin-impact-anti-cheat-driver-to-kill-antivirus.html> of the Genshin Impact vulnerability makes it clear you don’t even have to be a player of that game: the malware can install its own copy of the driver, and use that to crack your system, regardless. This would apply to other vulnerable drivers for hardware or software you don’t own: the mere existence of such vulnerable drivers is a danger to all current Windows systems. But it seems Microsoft has finally noticed that its notification system for vulnerable drivers isn’t working: What the program manager was saying boiled down to this: If you thought HVCI was protecting you from recent BYOVD attacks, you were probably wrong. Windows 10 hadn't updated the list in almost three years. That’s a long time to go without noticing that a system is broken ...
On Thu, 6 Oct 2022 14:36:36 +1300, I wrote:
Having Microsoft verify third-party drivers with a digital signature, so that Windows will block the loading of unsigned drivers, seemed like a good idea when it came in with Windows Vista. Enforcing quality control would remove a big source of crashes, as well as security loopholes.
But it seems the execution falls somewhat short ...
Another fun way that lowlifes have found to subvert this process <https://arstechnica.com/information-technology/2022/12/microsoft-digital-certificates-have-once-again-been-abused-to-sign-malware/> is to get Microsoft to sign a driver that won’t, on its own, exhibit any malicious behaviour, so it doesn’t trigger any alarm bells. Then you use a separate developer certificate to sign another piece of code that, when it loads and activates the Microsoft-signed driver, will trigger the malicious functionality. This gives you a stepping stone into the full level of trust that a Microsoft-signed driver enjoys. Treating proprietary software as a “black box” just doesn’t work. This would be much less likely to happen with Open Source, because it’s harder to hide things in plain sight.
participants (1)
-
Lawrence D'Oliveiro