Korset: Linux security thanks to static analysis

Sep 10, 2008

Coworkers at the University of Tel Aviv have presented a prototype for a new host-based intrusion detection system (HIDS) for Linux. Named Korset, it uses static code analysis and promises zero failures.

A host-based intrusion system (HIDS) models an application’s behavior and if the behavior deviates from the model, it sends an alarm. Earlier methods of intrusion detection depended either on static data derived from machine learning or on program policies created by developers. In the views of Professor Avishai Wool and kernel developer Ohad Ben-Cohen, the first method is susceptible to false positives and the second one costly.

Instead, Wool and Ben-Cohen use a behavioral model automated through static analysis of source code and object files resulting in control flow graphs (CFGs). Since most attacks are accompanied by system calls, the CFGs limit themselves to these calls and document the legitimate pattern for each application. If a program deviates from the pattern, the kernel ends the process.

Korset control flow graphics
Korset uses control flow graphs derived by static analysis from the source code.

Korset consists of two parts: a static analyzer in user space and a runtime monitoring agent in the kernel. The analyzer is drawn into the program’s build process and creates a CFG for each executable, object data and library. The Korset runtime monitor is built into the kernel. Once a detected program runs, the agent monitors any resulting system calls and compares them with those of the CFG model.

Wool’s and Ben-Cohen’s report to the Ottawa Linux Symposium 2008 (PDF) includes further details about their work, as does their presentation at the Black Hat US 2008 conference.

A Korset prototype download is available under GPLv3 terms. The developers designate the implementation as pre-alpha software not yet ready for use, but proof-of-concept.

Related content

  • Code Analysis

    Linux offers some sophisticated tools for understanding how malware can slip through the gaps in an unsuspecting application.

    more »
  • Moth: Virtual Testbed for Web Application Security

    The Bonsai Information Security firm has released Moth, a VMware image with a set of vulnerable web applications and scripts. It serves for testing and developing security scanners and can be instructional in all matters application security.

    more »
  • OSSTMM 3.0 Released

    The Institute for Security and Open Methodologies (ISECOM) announced the released of the Open Source Security Testing Methodology Manual (OSSTMM) 3.0.

    more »
  • Expert Security Intro

    Internet intruders have many ingenious ways of escalating privileges and hiding their presence once they get inside your system. The best protection is to keep them out in the cold.

    more »
  • System Alert

    The unhide forensics tool scans your system for inconsistencies to uncover hidden processes.

    more »

Comments

  • Won't protect apps that include an interpreter.

    If you apply this technique to an app that embeds an interpreter (mod_python, say), and programs written in the interpreted language can make system calls, then wouldn't the Korset analysis conclude that any sequence of system calls that any script could make was legitimate? That might well be "any arbitrary sequence", leaving Korset with no illegitimate sequences by which to recognize infiltration.

    Now, if Korset could analyze the script itself, not the interpreter, then you might get more information. But languages like Python and Ruby are so dynamic that static analysis can't usually tell you much, unless you restrict the language.

  • Not all that useful

    I watched a video of their Blackhat presentation, and while It sounds like a good idea when demo-ed on the simple apps the present, this HIDS does very little to protect against larger pieces of software where all an attacker needs to do is figure out where in the CFG their shellcode is running,and then get to a point where they can make the sysycalls they want (e.g. execve) and then write shellcode that makes all the relevant syscalls, which may not even increase shellcode size drastically as it could just be a loop through a set of integers which uses each char as a value for eax, where the other arguments are (currently) irrelevant, as long as the app doesn't crash.
comments powered by Disqus