23 ms·
My source: https://www.youtube.com/watch?v=wAzEJxOo1ts https://www.youtube.com/watch?v=wAzEJxOo1ts From my understanding the CS driver lives in the kernel spac
by sschueller 2y ago
My source: https://www.youtube.com/watch?v=wAzEJxOo1ts https://www.youtube.com/watch?v=wAzEJxOo1ts
From my understanding the CS driver lives in the kernel space and parses configs/applications downloaded in the user space. Hence the system even does a BSOD.
"CrowdStrike doesn't have kernel-level ACE" please provide your source.
- roblabla 2y ago> From my understanding the CS driver lives in the kernel space and parses configs/applications downloaded in the user space. Hence the system even does a BSOD. That's my understanding as well, but not quite the same as > execute arbitrary code on the kernel level without any checks At least for me, when we talk about kernel-level ACE, it's something like libcapcom[0], which allowed executing arbitrary unsigned code in the kernel. Here, the driver can only execute the code present within itself, which was signed by Microsoft. The configuration itself isn't signed by microsoft, but the config isn't code (at least, as far as I can tell - I see some people claiming the CS-0000.sys files are essentially bytecode, but have yet to see conclusive proof of this). Now, we could argue that it's weird that Microsoft signed a buggy driver, and MS should do better qualification of third-party drivers. But in practice, MS doesn't really vet driver quality. From what I can tell, the driver signing is mostly there so they can easily attribute provenance of drivers, and revoke the certs if it ends up in the hands of malicious actors. [0]: https://github.com/notscimmy/libcapcom https://github.com/notscimmy/libcapcom