MIT system can fix your software bugs on its own (by borrowing from other software)
New software being developed at MIT is proving able to autonomously repair software bugs by borrowing from other programs and across different programming languages, without requiring access to the source code. This could save developers thousands of hours of programming time and lead to much more stable software.
Bugs are the bane of the software developer's life. The changes that must be made to fix them are often trivial, typically involving changing only a few lines of code, but the process of identifying exactly which lines need to be fixed can be a very time-consuming and often very frustrating process, particularly in larger projects.
But now, new software from MIT could take care of this, and more. The system, dubbed CodePhage, can fix bugs which have to do with variable checks, and could soon be expanded to fix many more types of mistakes. Remarkably, according to MIT researcher Stelios Sidiroglou-Douskos, the software can do this kind of dynamic code translation and transplant (dubbed "horizontal code transplant," from the analogous process in genetics) without needing access to the source code and across different programming languages, by analyzing the executable file directly.
How it works
As an example, let's say you've written a simple computer program that asks the user to input two numbers and outputs the first number divided by the second. Let's also say that, in your code, you forgot to check that the second number is not zero (a division by zero is mathematically undefined).
CodePhage starts with a (bugged) application and two inputs – one that triggers no errors ("safe input") and one that does ("unsafe input"). Using a large database of applications, it finds one that can read and correctly process both inputs. In our case, the system would search a vast repository for a function that can divide two numbers safely.
"We have tons of source code available in open-source repositories, millions of projects, and a lot of these projects implement similar specifications," says Sidiroglou-Douskos. "Even though that might not be the core functionality of the program, they frequently have subcomponents that share functionality across a large number of projects."
The system differentiates between a "donor" program – the software from which the fix will be borrowed – and a "recipient" program – the bug-ridden code which the MIT system will attempt to fix.
The first step is to feed the "safe" input to the donor code and dynamically track which constraints are being imposed on the input variables. Then, the software does the same with the second, "unsafe" input and compares the two sets of constraints. The points of divergence between the two identify a constraint that was met by the safe input, but not by the unsafe one, and so is likely to be a security check that is missing from the recipient code.
In our example, the safe input would be the divisor being any non-zero number, and the unsafe input would be the divisor being zero. The MIT system would detect that the condition "divisor must be different from zero" is met by the safe input, but not by the unsafe one, correctly identifying that the check for this specific condition is missing from the recipient code and is the probable cause of the bug.
At this point, CodePhage will take all the discrepancies in the input checks in the donor software and translate them into the programming language of the recipient software. The system will then try to add the new checks to the source code of the recipient program in different parts of the code, until the unsafe input is processed correctly (and the program still behaves as expected when checked against a test suite).
Toward bug-free software?
"The longer-term vision is that you never have to write a piece of code that somebody else has written before," says MIT professor Martin Rinard, who was part of the study. "The system finds that piece of code and automatically puts it together with whatever pieces of code you need to make your program work."
Rinard and team say a developer could, for instance, reduce development and testing effort by omitting checks for illegal inputs, and then use their tool to automatically transfer in checks from more robust software, including closed-source, proprietary applications.
According to the researchers, in modern commercial software, security checks can take up 80 percent of the code – so the impact on programming time could, at least in theory, be quite substantial. What's more, while the system is currently limited to analyzing variable checks, the researchers say that the same techniques are also designed to track, extract and insert any computation, as long as the system is able to correctly identify the values assigned to the variables in the donor software.
The MIT system could also be used to transfer checks between different versions of the same application, to try and prevent newly released software patches and updates from introducing new bugs.
When tested on seven common open-source programs, CodePhage was reportedly able to patch up the vulnerable code every time, taking up to 10 minutes per repair. In future versions, the researchers hope to reduce this lag time as much as possible.
The advance was presented at the Association for Computing Machinery’s Programming Language Design and Implementation conference this month, and an open-access paper describing the system can be found online.