New Windows driver signature bypass allows kernel rootkit installs
Vulnerability & downgrade attack
- Exploit abuses Windows Update / servicing to downgrade kernel components or drivers to older, signed versions with known flaws.
- This bypasses driver-signature enforcement and allows kernel rootkits once an attacker already has admin-level control.
- Some see it as mainly a process failure (revocation / blacklist not managed well, downgrade paths too permissive) rather than a deep architectural flaw.
- Others note practical constraints: enterprises sometimes need downgrades for rollback, complicating strict version pinning.
Is this “really” a security boundary bypass?
- Microsoft’s position:
- UAC is not a security boundary; it’s a convenience layer for already-admin users.
- Admin-to-kernel is also not treated as a strong boundary; admins are part of the TCB.
- Many commenters push back:
- They expect driver signing to be a real boundary, so bypassing it should be high‑severity.
- They see Microsoft’s boundary definitions as self-serving and confusing to users.
Windows vs Linux/macOS security models
- Comparisons to Linux:
- Typical Linux systems let root freely load kernel modules; secure-boot/signature enforcement and SELinux are optional and often not hardened on desktops.
- sudo/polkit are viewed as comparable to UAC prompts; both can be socially engineered, and fake sudo prompts are easier to spoof.
- Comparisons to macOS / ChromeOS:
- Some argue Windows now has a strong architecture (e.g., Secure Desktop for elevation prompts) and is on par or better than macOS in some areas.
- Others say macOS and ChromeOS are more locked down with stronger sandboxing, SIP, driver moves to user space, and pervasive permission prompts.
Admin usage, usability, and blame
- A recurring theme: most real-world desktops (Windows, Linux, macOS) effectively treat the primary user as near‑root, via sudo, UAC, or similar.
- Some argue that if you don’t want someone to control a machine, don’t give them admin; enterprises already do this.
- Others emphasize mandatory access control (e.g., SELinux) as a way to limit even admins, which Windows largely lacks.
Lockdown vs user control
- Some advocate fully locking down kernel access to protect ordinary users and data.
- Others insist users must retain the option to run arbitrary kernel code on their own machines, and see increasing lockdown as “console/phone-style” control.