3 ms·

Unless you have a source, you should really avoid spreading misinfo here. CrowdStrike doesn't have kernel-level ACE. It has a buggy configuration parser, and th

Unless you have a source, you should really avoid spreading misinfo here. CrowdStrike doesn't have kernel-level ACE. It has a buggy configuration parser, and they pushed a corrupted config that triggered those buggy codepath in the parser.

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
dathinab 2y ago
there are some places claiming that this "config" language is so flexible that it's basically a interpreted scripting language but AFIK no sources I trust have yet claimed it but it's probably where the idea comes from

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

dathinab 2y ago

there are some places claiming that this "config" language is so flexible that it's basically a interpreted scripting language but AFIK no sources I trust have yet claimed it but it's probably where the idea comes from