4 ms·

The file was just full of null bytes. It's very possible the signature validation and verification happens after the bug was triggered.

wk_end 2y ago
"Load a kernel module and then verify it" is not the way any remotely competent engineer would do things. (...which doesn't rule out the possibility that CS was doing it.)
- justinclift 2y ago
  The ClownStrike Falcon software that runs on both Linux and macOS was incredibly flaky and a constant source of kernel problems at my previous work place. We had to push back on it regardless of the security team's (strongly stated) wishes, just to keep some of the more critical servers functional. Pretty sure "competence" wasn't part of the job description of the ClownStrike developers, at least for those pieces. :( :( :(
  - soraminazuki 2y ago
    ClownStrike left kernel panics unfixed for a year until macOS deprecated kernel extensions altogether. It was scary because crash logs indicated that memory was corrupted while processing network packets. It might've been exploitable.
usr1106 2y ago
Haven't used Windows for close to 15 years, but I read the file is (or rather supposed to be) a NT kernel driver. 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?
- dagaci 2y ago
  Think more, imagine that the your CrowdStrike security layer detects an 'unexpected' kernel level data file. Choice #1 Diable security software and continue. Choice #2 Stop. BSOD message contact you administrator There may be nothing wrong with the drivers.
  - derefr 2y ago
    Choice #3 structure the update code so that verifying the integrity of the update (in kernel mode!) is upstream of installing the update / removing the previous definitions package, such that a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state. (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.)
    - warkdarrior 2y ago
      > a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state Fantastic solution! You just gave the attackers a way to stop all security updates to the system.
      - monocasa 2y ago
        When you can't verify an update, rolling back atomically to the previous state is generally considered the safest option. Best run what you can verify was a complete package from whoever you trust.
      - JohnBooty 2y ago
        No, that doesn't follow. 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.

wk_end 2y ago

"Load a kernel module and then verify it" is not the way any remotely competent engineer would do things. (...which doesn't rule out the possibility that CS was doing it.)

justinclift 2y ago
The ClownStrike Falcon software that runs on both Linux and macOS was incredibly flaky and a constant source of kernel problems at my previous work place. We had to push back on it regardless of the security team's (strongly stated) wishes, just to keep some of the more critical servers functional. Pretty sure "competence" wasn't part of the job description of the ClownStrike developers, at least for those pieces. :( :( :(
- soraminazuki 2y ago
  ClownStrike left kernel panics unfixed for a year until macOS deprecated kernel extensions altogether. It was scary because crash logs indicated that memory was corrupted while processing network packets. It might've been exploitable.

usr1106 2y ago

Haven't used Windows for close to 15 years, but I read the file is (or rather supposed to be) a NT kernel driver. 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?

dagaci 2y ago
Think more, imagine that the your CrowdStrike security layer detects an 'unexpected' kernel level data file. Choice #1 Diable security software and continue. Choice #2 Stop. BSOD message contact you administrator There may be nothing wrong with the drivers.
- derefr 2y ago
  Choice #3 structure the update code so that verifying the integrity of the update (in kernel mode!) is upstream of installing the update / removing the previous definitions package, such that a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state. (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.)
  - warkdarrior 2y ago
    > a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state Fantastic solution! You just gave the attackers a way to stop all security updates to the system.
    - monocasa 2y ago
      When you can't verify an update, rolling back atomically to the previous state is generally considered the safest option. Best run what you can verify was a complete package from whoever you trust.
    - JohnBooty 2y ago
      No, that doesn't follow. 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.