MIT System Fixes Software Bugs Without Access To Source Code
jan_jes writes: MIT researchers have presented a new system at the Association for Computing Machinery's Programming Language Design and Implementation conference that repairs software bugs by automatically importing functionality from other, more secure applications. According to MIT, "The system, dubbed CodePhage, doesn't require access to the source code of the applications. 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."
And to whom do you file the bug report again?
I can just imagine it now "Yeah, we run this cool thing called CodePhage which patched the software, but now it broke". They'll laugh at you and hang up.
This sounds like an automated system for mangling together random bits of software and hoping you still have something usable.
Sounds totally cool. Also sounds like complete fiction.
Lost at C:>. Found at C.
.... It causes software bugs by automatically importing malware functionality from other, less secure applications.
An excellent idea. On a very closely related thought this same sort of idea can be used to translate software so that what ran on older legacy platforms or incompatible platforms can automatically be able to run on newer hardware. Imagine you buy the latest greatest Cray SuperComputer Watch and it will run all your Android, Apple Watch, iPhone, MacOSX, Windows, Unix, DEC, Exidy, TRS-80, CPM and other software. Suddenly you can upgrade your hardware without the worry of losing access to your data. We need this in a big way.
I was really confused, because of the context my brain immediately went to Team Foundation Server. I was like, "What? The Fucking Summary never mentioned TFS... oooooh, I see...."
It is called a Rubber Band workaround.
Working with legacy systems without access to Source, however needs additional features. Intercept Pipes, data packets, or reports generated, then use its information to filter and add additional information.
It is a rubber band solution because it can break from a brand new unknown variable, and requires layers of fixes and workarounds to keep it running.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The NSA is going to love this one. If the Codephage can inject "clean" code, there's nothing that prevents it from being revamped to inject malicious code.
Alternatively, if your site needs a level of security where you need this type of "live" patching, you need a level of security that would prevent CodePhage from making the updates in the first place.
Sounds like it might be a useful test and bug detection tool, but not for live environments.
We are the 198 proof..
Woo hoo. Finally I can treat the copy protection and CONSTANT recurring key checks as bugs in the software I have paid for!
No one knows what it will do before just trying it.
and gosh it would never occur to anyone to make a backup first
OS/2 at being some modular and object oriented allowed you to fix some bugs on the Workplace Shell (Desktop Interface) (WPS) without access to the source code of it. The trick of OS/2 is that it uses SOM in the middle between the GUI and the Desktop.
Since all the WPS where objects, you just grabbed the clock object (WPClock), and create a child from it, you can incorporate more functionality, or remove the functionality that you didn't like. So on OS/2 you disabled the parent WPClock object and tell that NewWPClock child should be the one that everyone must use.
It is a different way from what this article says, but it does not means this is the first time that someone can extend/fix/improve a program without it's source code.
A user calls and says they have a problem with program x so they call me. When they get there, they cannot reproduce the bug. We assume that the software know that it is whipped once I come into the picture so it fixes itself. You would not believe how many times this has happened over 30+ years.
It's 2015, users are not that dumb nEOF
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
No, there was no sarcasm. We need legacy support to move data forward.
The user is slowing down and doing it right when you're there. When you're elsewhere, they do it fast and they do it wrong. Tell them to slow down, close the case
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
C is a powerful language. I shouldn't have to give up that power because some other schmoe doesn't know how to handle it safely. Come the think of it, that applies to a lot of things.
If you're automatically taking code from a more secure application and injecting it into a "stable" application, that' alters the stable application and invalidates any testing that's been performed. Sure, the intention is fixing a "bug" or a vulnerability but you're changing application behavior potentially and creating a bigger set of problems. From a purely academic sense it's definitely intriguing but I don't think I'd want anything I'm supposed to be supporting leveraging this as a catch-all.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
So, DIODE is really cool. It looks like it does the same thing you'd do with IDA and a fuzzer. It only finds integer overflows, but still really cool. CodePhage just reads like a giant ball of WTF
It has been my experience that software comes with a EULA that says there is no warranty.
With so much copyright rhetoric going around I can't help but to think this will come back and bite someone bad.
This is like a virtual machine for all instances of strcmp?
Religion is what happens when nature strikes and groupthink goes wrong.
In fact, you are correct. The article clams they don't have to have the source, but that is only partly true. The recipient, the program that has a bug, must have the source code. The donor, the program that does not suffer from the bug, does not need to have the source code. And this is perhaps the interesting part.
So, say you are creating an open source Office program, and you obviously need to open .doc files. You have mostly everything working, but now you have this one file that crashes your program, but doesn't crash Office. Instead of spending the time to find it, CodePhage allows you to point it at your source code, and at Office, and it will build an internal set of debug like codes of each program. You need to run it on your code with a working example file, then run it with the non working file, it will figure out what you are doing, then it will open the same file with Office, find out if you are doing something out of order or if there is a check you aren't running, and the article describes in a little more detail how it works, though not the nitty gritty. It then modifies your source code, and runs it again, and see if the changes fix it, if not it will continue until it does.
The say in general the bugs they tested were fixed in 20 to 90 minutes.
NDxTreme Content on the Edge.
Unfortunately, this doesn't fix those type of bugs, because they aren't bugs. It also cannot patch a program without the sourcecode, at least not by itself.
What you really want is to use one of these project that translate executable code into, say, c or c++, and from there you could try to do this, if it runs on those systems and can handle anything other than x86 code.
NDxTreme Content on the Edge.
The article did mention checking to see if things were being done out of order, I would think this could be expanded toward race conditions.
NDxTreme Content on the Edge.
So, there are already computers that can automatically find vulnerabilities and patch them (and exploit them).
https://cgc.darpa.mil/
http://www.cybergrandchallenge...
What happens when you run it against itself over and over?
Or is this the first non-trivial bug-free piece of software ever written?
END OF LINE.
Things like this have been done since... the start of computing? I remember patches like this were done on 8 bitters (c64, cpc, ...) and later 16 bitters (amiga, atari, pc, ...). For games they came in the form of cheatmodes or to enable piracy.
On a long enough timeline, the survival rate for everyone drops to zero.
Wow! This is awesome! I am sure Adobe will pass the savings onto the customer!
I art more snarky, and terse than thou. I art Slashdot!