Once a vulnerability has been detected the system must be able to repair the application so it cannot be exploited. This involves changing the program so that it becomes immune to that attack and possibly to similar attacks as well. As a simple example, a program with a buffer-overflow vulnerability might be changed to limit the number of characters read. Repairing a program is different from using diversity to protect it; the latter might only change a code injection attack that exploits the vulnerability into a detectable crash. Repairing a program is also different from generating a signature; the latter might only filter out any network packet that appears to be exploiting the vulnerability. We will use information and capabilities from the AIR, Strata, and our signature generation analyses towards the goal of repairing programs to remove underlying vulnerabilities.

Traditionally programs are repaired by presenting a description of the problem to the software vendor, waiting for a patch to be released, shutting down the program, installing the patch, and restarting the program. This process is too slow for critical, enterprise software and untenable in situations where restarting the program is not an option. In Helix, we will fix certain classes of problems automatically by transforming programs. Most program transformations, such as compiler optimizations or the low-level diversity transformations performed by Strata, are designed to preserve the original program semantics. A successful repair is adaptive and necessarily changes the program’s behavior, especially with respect to the vulnerability. However, it is also critically important that a repair not interfere with other aspects of a program’s behavior.

Related Publications

• Automatic Documentation Inference for Exceptions
• A Metric for Software Readability
• Modeling Bug Report Quality