Building a reactive immune system for software services

  • Authors:
  • Stelios Sidiroglou;Michael E. Locasto;Stephen W. Boyd;Angelos D. Keromytis

  • Affiliations:
  • Network Security Lab, Department of Computer Science, Columbia University;Network Security Lab, Department of Computer Science, Columbia University;Network Security Lab, Department of Computer Science, Columbia University;Network Security Lab, Department of Computer Science, Columbia University

  • Venue:
  • ATEC '05 Proceedings of the annual conference on USENIX Annual Technical Conference
  • Year:
  • 2005

Quantified Score

Hi-index 0.00

Visualization

Abstract

We propose a reactive approach for handling a wide variety of software failures, ranging from remotely exploitable vulnerabilities to more mundane bugs that cause abnormal program termination (e.g., illegal memory dereference) or other recognizable bad behavior (e.g., computational denial of service). Our emphasis is in creating "self-healing" software that can protect itself against a recurring fault until a more comprehensive fix is applied. Briefly, our system monitors an application during its execution using a variety of external software probes, trying to localize (in terms of code regions) observed faults. In future runs of the application, the "faulty" region of code will be executed by an instruction-level emulator. The emulator will check for recurrences of previously seen faults before each instruction is executed. When a fault is detected, we recover program execution to a safe control flow. Using the emulator for small pieces of code, as directed by the observed failure, allows us to minimize the performance impact on the immunized application. We discuss the overall system architecture and a prototype implementation for the x86 platform. We show the effectiveness of our approach against a range of attacks and other software failures in real applications such as Apache, sshd, and Bind. Our preliminary performance evaluation shows that although full emulation can be prohibitively expensive, selective emulation can incur as little as 30% performance overhead relative to an uninstrumented (but failure-prone) instance of Apache. Although this overhead is significant, we believe our work is a promising first step in developing self-healing software.