The file was just full of null bytes.
It's very possible the signature validation and verification happens after the bug was triggered.
It's very possible the signature validation and verification happens after the bug was triggered.
(...which doesn't rule out the possibility that CS was doing it.)
Pretty sure "competence" wasn't part of the job description of the ClownStrike developers, at least for those pieces. :( :( :(
Are those drivers signed? Who can sign them? Only Microsoft?
If it's true the file contained nothing but zeros that seems to be also kernel vulnerability. Even if signing were not mandatory, shouldn't the kernel check for some structure, symbol tables or the the like before proceeding?
Choice #1 Diable security software and continue. Choice #2 Stop. BSOD message contact you administrator
There may be nothing wrong with the drivers.
(This is exactly how CPU microcode updates work — the CPU “takes receipt” of the new microcode package, and integrity-verifies it internally, before starting to do anything involving updating.)
Fantastic solution! You just gave the attackers a way to stop all security updates to the system.
For most systems, a sensible algorithm would be "keep running the last known good definition, until we get the next known good definition"
In other words: ignore bad updates but keep checking for valid ones. That doesn't mean you've permanently lost the ability to update.
Of course, for some systems, different behavior might make more sense.
Brillant! [sic]
And yes Windows drivers are signed. If it had been a driver it would just have failed to load. Nowadays they must be signed by Microsoft, see https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
The kernel driver was signed. The file it loaded as input with garbage data had seemingly no verification on it at all, and it crashed the driver and therefore the kernel.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...