Slash Boxes

SoylentNews is people

posted by n1 on Monday July 06 2015, @09:32PM   Printer-friendly
from the human-obsolescence dept.

MIT computer scientists have devised a new system that repairs dangerous software bugs by automatically importing functionality from other, more secure applications.

Remarkably, the system, dubbed CodePhage, doesn’t require access to the source code of the applications whose functionality it’s borrowing. Instead, it analyzes the applications’ execution and characterizes the types of security checks they perform. As a consequence, it can import checks from applications written in programming languages other than the one in which the program it’s repairing was written.

Once it’s imported code into a vulnerable application, CodePhage can provide a further layer of analysis that guarantees that the bug has been repaired.

[...] Sidiroglou-Douskos and his coauthors — MIT professor of computer science and engineering Martin Rinard, graduate student Fan Long, and Eric Lahtinen, a researcher in Rinard’s group — refer to the program CodePhage is repairing as the “recipient” and the program whose functionality it’s borrowing as the “donor.” To begin its analysis, CodePhage requires two sample inputs: one that causes the recipient to crash and one that doesn’t. A bug-locating program that the same group reported in March, dubbed DIODE, generates crash-inducing inputs automatically. But a user may simply have found that trying to open a particular file caused a crash.

[...] “The longer-term vision is that you never have to write a piece of code that somebody else has written before,” Rinard says. “The system finds that piece of code and automatically puts it together with whatever pieces of code you need to make your program work.”

“The technique of borrowing code from another program that has similar functionality, and being able to take a program that essentially is broken and fix it in that manner, is a pretty cool result,” says Emery Berger, a professor of computer science at the University of Massachusetts at Amherst. “To be honest, I was surprised that it worked at all.”

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Monday July 06 2015, @11:10PM

    by Anonymous Coward on Monday July 06 2015, @11:10PM (#205885)

    I completely agree that a problem with something like this is that it's impossible for the code to properly anticipate the intent of the programmer but I was just trying to clarify that the intent of this code corrector wouldn't be for someone to try and fix already signed code but for someone to find bugs in code before signing it. Perhaps the compiler itself has a bug or at least there is a bug that doesn't manifest itself within the source code but only manifests itself after the code has been compiled due to how the compiler itself works. What something like this could do is attempt to find such bugs. However, I would argue that this isn't anything new and that existing compilers already attempt to identify potential crash points in a program and that compiler bugs are just as likely as bugs in this software itself. A programmer may misunderstand how a compiler interprets a piece of code but the proper solution isn't to create a separate program that tries to find potential crashes but to try and ensure the compiler itself works properly to identify potential crashes. This is essentially trying to solve one layer of problems (ie: compiler problems, programmer problems that can be identifies by good compilers, bad programmers that don't know how to avoid bad code) with another (another layer of code that code must go through to get checked for bugs).