Kernel runtime security instrumentation

Posted Sep 8, 2019 6:48 UTC (Sun) by jezuch (subscriber, #52988)
In reply to: Kernel runtime security instrumentation by Cyberax
Parent article: Kernel runtime security instrumentation

Well, my thought was that you would investigate while limiting potential damage so that you don't alert the attackers so that you have some more time to identify them. But I'm not a security expert and this sounds dangerous even to me so I don't expect this to be a plausible scenario.

Kernel runtime security instrumentation

Posted Sep 8, 2019 7:08 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's pretty clear that the idea here is to create something like Windows antiviruses, an automatic tool to detect malicious patterns and try to counteract them.

Unfortunately, the patch authors don't seem to have nearly enough experience with that kind of stuff. Modern Windows antiviruses have multiple layers or defenses, they intrude into the very heart of the OS. Windows itself scans and checksums its internal control structures (PatchGuard, CodeIntegrity), and antiviruses tune it up to 11. Which is kinda awe inspiring - it's like watching CoreWar.

Yet it's still not enough. All the OS protections have been bypassed ( https://www.symantec.com/content/dam/symantec/docs/securi... ) and malware now routinely bypasses antiviruses. This is because attacks don't get worse, they always keep getting better.

Kernel runtime security instrumentation

Posted Sep 11, 2019 5:05 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

Ok, I'm not sure how relevant it is, but that paper was from over 10 years, when Symantec was all bent out of shape that Microsoft's drivers were going to be able to do things it's drivers - written largely without code review and QA - couldn't.

Some rumblings about anti trust later, an API was provided, Symantec realized windows was a dying revenue stream, and you haven't seen much work in the area since. So it's a bit of an unknown.