Korset statically preconstructs a Control Flow Graph (CFG) of an application it wants to protect. If such a CFG is successfully created (currently there are severe limitations about the supported applications), every legitimate system call sequence of the application is represented as a path in the CFG. That means that every deviation from the CFG cannot have been issued by the original application, and thus must be a (code injection) attack. So every alarm that is raised by Korset is justifiable. That’s zero false positives. BUT! That’s definitely not “zero failures”. Attacks can still go unnoticed – These are false negatives – and until the precision of the models will not be improved – Korset’s going to have lots of those.
13
Sep
Read the Korset paper [PDF] published in the proceedings of the Linux Symposium.
That paper briefly describes the concept of Code-based Intrusion Detection and then it delves into implementation issues.
11
Sep
Korset is still only a proof of concept for Code-based Intrusion Detection – it cannot yet be used to protect real world applications. There is a lot to improve, and bugs to fix, but the really big thing Korset currently lacks is advanced data flow analysis, with which a reasonable indirect calls support can be provided. Supporting that will pave the way for protecting real world servers.
Korset aims to prevent code injection attacks by looking for anomalies in the control flow of the application it’s protecting. This has little to do with classic computer viruses, which are traditionally being executed by the user himself and, from the OS perspective, are as legitimate as any other piece of software. You need anti-virus software to find them. Korset will never do that. It has completely different goals.
