MIT Invents Automatic Bug Repair

HardOCP News

[H] News
Joined
Dec 31, 1969
Messages
0
Wouldn't it have been great if the developers of the PC version of Batman: Arkham Knight had access to something like this. :D

MIT researchers presented 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.
 
I've read their paper on this (http://people.csail.mit.edu/fanl/papers/codephage-pldi2015.pdf) and I'm not really sure how useful it is - maybe I'm not understanding it correctly.

They use an example in the paper where their codephage finds a spot in a source program where it will overflow a buffer where the user given input to the program is too large. This will cause undefined behavior when it happens - usually a crash in my experience, but not always. So then they find a spot in a "donor" program where it handles such large input with no error and - very cleverly - stitches that code into the source program so it no longer has the error with big input.

The problem as I see it is the way the donor program appears to handle the situation where the input is too large is that it just returns/exits thus terminating execution of the program. So it appears to me that it fixed the bug where the source program probably crashes with some error message about overflows that the user probably won't understand to where it now just terminates with no error - leaving the user wondering what the heck just happened. It's not really a better situation is it?

In the case of the big input, in some programs you might want it to terminate with a user understandable error. In some programs you might want to truncate the input and keep going. The right answer is a design decision. You might call it "programmer preference." How can it know what the programmer wants the program to do when the programmer hasn't even figured that out yet?
 
I think the part you're missing is that these are security bugs. The choice isn't between crashing with an error and silently exiting; it's between getting owned and silently exiting. I imagine some of the generated patches instead return from the function, call some error handler, etc., but those will often just create another bug somewhere else.

That said, I think the general approach (though perhaps not this particular implementation) can also fix some non-security bugs. Raymond Chen has blogged about a number of application compatibility shims and workarounds in Windows to cope with programs that misuse the Windows APIs in some way, or that depend on undocumented internals of Windows. I think these programs could be fixed by comparing them with examples of proper uses of the APIs or that obtain what they're looking for through a related, but documented interface (e.g., calling an API function instead of directly reading reserved fields of a structure). You can write a format specification for uses of these APIs/reads of internal structures in the same way as file formats, so the taint tracking approach still applies. I asked Stelios about this after his PLDI talk and he agreed, but Code Phage itself is built on Valgrind and thus doesn't run on Windows, so it can't be immediately tested.
 
meh, misleading topic. sounded like they miraculously solved the halting problem.
 
The choice isn't between crashing with an error and silently exiting; it's between getting owned and silently exiting.

The latter then is certainly more desirable that the former, but neither is ideal. Lets say this was some online application that services multiple users, now you've given an attacker a tool to remotely shut down your app whenever he wants. And you're not logging the event or anything, so your app would just be shutting down unexpectedly and you would have no idea why.
 
Back
Top