Slashdot Mirror
Fixing Bugs, But Bypassing the Source Code
shreshtha contributes this snippet from MIT's Technology Review: "Martin Rinard, a professor of computer science at MIT, is unabashed about the ultimate goal of his group's research: 'delivering an immortal, invulnerable program.' In work presented this month at the ACM Symposium on Operating Systems Principles in Big Sky, MT, his group has developed software that can find and fix certain types of software bugs within a matter of minutes." Interestingly, this software doesn't need access to the source code of the target program.
run this software before running ClearView on it first. Imagine what this could do if it had a bug in its code!
was it ever applied to itself? ... and did it gain conciousness?
Another interesting project that Microsoft will probably buy out and kill in the egg.
A "whatcouldpossiblygowrong". Along with, just to be on the safe side, a "colossustheforbinproject", a "shodan", a "hal", a "skynet" and probably a bunch of others that I'm forgetting right now.
Has anyone cracked "Hello World" yet?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It's a good idea, but here's the issue: software isn't meant to be immortal. It's meant to grow, get better, offer more functionality; imagine if all software stopped growing in Word 1.0 or PrintShop Pro? We'd never have all these great alternatives for office products or Photoshop/Gimp/etc.
This doesn't support innovation and improvement, and that's the cornerstone of technology improvement.
Of course it can fix a program without the source code. The source code is not the part that runs. Rather it is the executable, which is just a file of bytes. Find/Replace one sequence of bytes with another, and you've changed the program without the source. It's not a big deal. Viruses have been doing this sort of thing for decades.
When our name is on the back of your car, we're behind you all the way!
It checks a bunch of identical machines for a set of know bugs, then applies a bunch of predermined patches until one works.
That's nice, but not what was promised.
This doesn't support innovation and improvement, and that's the cornerstone of technology improvement.
Please allow myself to introduce... myself.
How long before "it" becomes self-aware? This is the beginning of the end, folks... By 2012 it'll be all over.
If you want news from today, you have to come back tomorrow.
code. I would argue that would be the worst way to do it.
Look at the hex, make changes. The conept is no different then inserting or replacing a JMP to get around software protection.
The Kruger Dunning explains most post on
The very first time ClearView encounters an exploit it closes the program and begins analyzing the binary, searching for a patch that could have stopped the error.
Think of how much bullshit would go out of business if people were to do the same thing (i.e. sit down and think it over) when presented with some unusual idea.
Who will fix the bugs in the ClearView program?
Dammit! Let me fix that..
"This doesn't support innovation and improvement, and that's the cornerstone of technology evolution."
I'm thinking the gist was there at least..
May be isnt immortal and invulnerable, but is pretty near...
- self repairing
- self replicating
- survive large amounts of time with minor changes
If the programs that Clearview is monitering/patching are the target, wouldn't it make sense for an attacker to focus on Clearview first? Perhaps even alter its function to serve the purposes of the attacker instead of the user. Why attack the programs it is patching when you could hit Clearview and gain the ability to hijack everything it is patching?
Sigs are too short to say anything truly profound so read the above post instead.
I wonder if we should turn that software loose on itself and see what it finds.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
This is absolutely correct, so long as one assumes that Windows systems are the only systems, and Linux developers aren't human.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
It would totally wipe out Microsoft's current business model. I think they better wait until they sucker everyone into software rental agreements before this is unleashed on Windows.
.
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
So how long before someone uses this to "patch" DRM and/or Windows Genuine Advantage? They interfere with my computer's functions, cause software/systems to fail out of nowhere, and are an unwanted inclusion in many programs. Yep--sounds like bugs to me!
Which means it won't be long before patches are available. Cue the angry horde of DMCA attorneys....
Never confuse movement with action. --Hemingway
"Keeping the system going at all costs does seem to have merit," adds David Pearce, a senior lecturer in computer science at Victoria University in Wellington, New Zealand.
At all costs? What sort of systems does he imagine this would be useful for? Flight control computers? Industrial robots? Nuclear reactor control systems? Radiation therapy machines?
Or just systems where people's lives aren't potentially in jeopardy when "Keeping the system going at all costs" results in the system going haywire? When certain systems have something go wrong and end up in an unanticipated state, the thing you want to do is reset them to a known state, not just keep them going in hopes the software can get things under control.
There has been no silver bullet in Software Engineering, not for attacker and not for defenders. I highly doubt this is one. From the article, I gather that this is actually some kind of macro Design by Contract based self-fixer. This means it is at best just as good as the people writing the contracts. It will however fail for more complex contracts, which are needed frequently in practice, unless it can get over all sorts of theoretical and practical limitations. And it will make behavior non-predictable, since your software could be patched at any time.
I would say this is a pretty bad idea, both from a security point of view and from a data-integrity and software reliability point of view.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
When a potentially harmful vulnerability is discovered in a piece of software, it takes nearly a month on average for human engineers to come up with a fix and to push the fix out to affected systems
Yes. It takes us 5 seconds to an hour to actually come up with the fix, the remainder of the month is spent in bureaucratic hell - sitting in a trouble ticket queue, sitting in a verification queue, sitting in a QA manager's inbox, sitting with the communications team.
Clearview, if it does what it says on the tin, only addresses the 5 second problem. Any "sane" dev shop would still run the resultant patch through the many cogs and loops of modern software management. You won't get your hole patched any quicker, you'll just have shifted the coders' attention away from your own app's bugs, and onto Clearview's bugs. Net gain: less than zero.
Theoretically and conceptually, it's an interesting tool (you know, like Intercal). It just doesn't really fit in the industry, IMHO.
-Billco, Fnarg.com
terrible name. Come on ClearView is the best you could come up with?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
You thought you'd fix your own post by replying to an AC? Good job. Now you can make a third post to fix that!
I want my CPU to say, "oh, these are the instructions you meant to execute..."
(Granted, I'd bet there are optimizations present in CPUs that do this today, but they're not supposed to introduce changes in behavior.)
"Entscheidungsproblem". You'd think a professor of CS at MIT would have heard of it.
That's true for some/most cases where we're still exploring how to develop a piece of software around a task. Other pieces of software are well defined and don't really need to be evolved. How many times do you need to recode linked lists until their good enough? I think we're reaching a similar consensus with designing UIs, where some architectural patterns will remain consistent across languages. Like setting up a text box or button. As these pieces become refined or 'immortal' it will free us lowly humans up to work on other problems like fixing that damn vending machine that always clings to my precious snacks.
How long before it decides that human existence is a bug?
So Microsoft won't be using it then ...
More like...
(user to IT): When I left last night, I had Word open in Windows on this PC... when I came back this morning, the document open in GVim in Linux!
I'm sick of the stupid headlines I've been reading about the so called projects of MIT students lately... I mean, clearly an 'immortal invulnerable program' is impossible at least for practical purposes by definition(they're dependent on the underlying OS, on other softwares and last but not least on the hardware integrity). Other recent headlines about their CS students claiming to be able to tell who's gay based on their facebook friends.... pff omg, when did it all get so preposterous. Why aren't they more honest about the reach of their ambitions. If you take these teachers words to the letter it seems like they don't know what's theoretically sound and what isn't...
This type of stuff, like your friend did, has been written since the 1960s. It doesn't really work, unless the input code is written by slackers or idiots.
I'm fairly certain I've seen this type of code written in a few lines of perl.
A programmer with skill will KNOW how to write maintainable, readable, reusable code and simply do it. If fact, when pressured to not follow best practices, I suspect he will call in sick a few days to "help" management come to their senses.
If someone actually earned a masters from this, that graduate program should be laughed out of existence. OR, you are explaining it very well.
This is completely useless for any real application and for any complicated bugs. I've dealt with this for many many years. It sounds good in theory, but it simply doesn't work in the real world.
First of all, if you have a binary image of a program in some read only place, you could just compare to the running/working image to see if it were compromised and reload the original if it were. Admittedly, that can be a lot of work and ClearView might be more efficient. But, if it's just checking the behavior of the program, what's to keep hackers from getting their own copies of ClearView and figuring out how to game it, just like any other detection software. That is, making hacked programs perform so that they seem to be well behaved. Of course, if the idea is to turn the compromised software into a bot that is continuously spewing stuff out through the ethernet port, that might be hard to hide. But would you need ClearView to check that?
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Martin Rinard is a talented man with the largest ego in academia. Of course he is "unabashed"; he's never been "abashed" for a moment in his life. Every research project Rinard has completed has been the one he claimed would scoop and shut down all other computer scientists' efforts. Take any claims he makes with a big grain of salt. It's not that he's a fraud, it's just that history shows he isn't nearly as godlike as he thinks or claims to be.
Posted anonymously because I don't need Rinard as an enemy.
What a bunch of crapola.
Finding and fixing bugs, as any programmer knows, is anything but a simple and mechanical procedure.
About all ClearView can do is go "Oh, the stack has been bashed, let's NOP out the call to this code"
Compare this to the amount of work to find and fix an off-by-one error or an unset pointer.
There is no comparison.
From TFA:
When something goes wrong, ClearView detects the anomaly and identifies the rules that have been violated. It then comes up with several potential patches designed to force the software to follow the violated rules. (The patches are applied directly to the binary, bypassing the source code.) ClearView analyzes these possibilities to decide which are most likely to work, then installs the top candidates and tests their effectiveness. If additional rules are violated, or if a patch causes the system to crash, ClearView rejects it and tries another.
reminded me of another ingenious software application:
Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix. You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden to sedulously avoid it, it is not unexpected, and thus not beyond a measure of control. Which has led you, inexorably, here. ... ...
The first matrix I designed was quite
naturally perfect, it was a work of art, flawless,
sublime. A triumph equaled only by its monumental
failure.
she stumbled upon a solution whereby nearly 99.9% of all test subjects accepted the program, as long as they were given a choice, even if they were only aware of the choice at a near unconscious level. While this answer functioned, it was obviously fundamentally flawed, thus creating the otherwise contradictory systemic anomaly, that if left unchecked might threaten the system itself. Ergo, those that refused the program, while a minority, if unchecked, would constitute an escalating probability of disaster.
So, the solution to any program failure is creation of Zion, (the rest of the idea here is left to the imagination of the reader.)
You can't handle the truth.
Sounds just like the way your everyday virus scanner works.
http://en.wikipedia.org/wiki/Rice's_theorem
Can I get my star now?
People this is what we get when people grow up with Windows.
Isn't this already done with the "Hello World" program?
But seriously all software depends on hardware, you would really amaze me if you had a contiguous area of current that kept on fixing itself
Hmmm. Sounds like some CS urban legend. Never heard - not once - of a "thesis grade". Pass, no-pass, conditional pass. I didn't receive a grade myself. Just a diploma. Be great for those kind of folks that put GPA's on their CV, though.
46 & 2
It rates far too high on the thisAlgorithmBecomingSkynet index.
Seriously, why the hell is this news on slashdot?
This certainly isn't a new idea, and it'll meet the same fate as existing ideas, a quick death as someone figures out how to use it to cause more damage than good.
How does it know the difference between intentional and accidental? It doesn't. This is why compilers can't fix programmer bugs, they can at best warn or error on them. The compiler really is the most likely part of the process to find and fix any bugs that can be automagically found in a closed system.
'find a potential patch' ?
I have that, its the 'Check for updates' button.
Yes I realize that its trying to detect runtime errors and correct those, but anyone with half a clue about CS knows multiple reasons why this simply doesn't work. The first and foremost reason being that it will take something intentional, classify it as a bug and 'fix' it. In effect breaking it. The only way to fix this is to keep a big exception list that constantly needs updated ... which will also have bugs. Rinse, repeat for the rest of eternity.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Missing, old, or obsolete functionality are not bugs.
So it patches binaries thus rendering the digital signature invalid. This makes your system more vulnerable to attacks that modify binaries maliciously.
So, when ClearView finds something wrong it magics up a patch, using some analysis based on previous execution path behavior or something (waves hand dismissively), then installs the patch directly into the application code.
Maybe I'm just oversimplifying things, but what about just taking a snapshot of the application and replacing the whole thing, shotgun-style, from read-only media when the binary changes unexpectedly? Wouldn't that be a hell of a lot simpler? A Perl-based daemon wielding the mighty md5 utility could do that in, what, 100 lines of code and comments?
To prove the correctness of ClearView, we ran it against itself, and found no bugs, no vulnerabilities,.... nothing at all!
The program will just realise that all programs break because of user inputs, and will patch programs so users can't interact with them.
There are more promising approaches, mostly involving some form of checkpointing. The idea is that when an error is detected, you go back to the previous checkpoint at which things were going well, determine what input caused the problem, reject that input, and continue forward from there. In some cases, you have a second, different program checking the outputs from the first. This sort of thing has been used in telephony, and Tandem, before HP acquired it, was big on this sort of thing.
The clever thing to do is to collect the failing cases and, from them, build a model of what triggers the bug. There's been work on automated crash dump analysis that does this sort of thing, at both HP and Microsoft.
the complete article has a lot more information:
http://www.cs.washington.edu/homes/mernst/pubs/automatic-patching-sosp2009.pdf
you automatically have the source
patch a few bytes and off you go
proud caffeine whore
If the bug isn't fixed in the source code, the bug isn't fixed. This solution becomes a crutch upon which poor programmers depend until everything stops working altogether.
Help stamp out iliturcy.
"How many times do you need to recode linked lists until their good enough" WTF???
If FUD is applied to proprietary software vendors, they fear that disclosing their software bugs might dilute their credibility among customers.
Slashdot = Sarcasm
First nigger post I've ever seen here that got modded "Funny."
The mods must be the sense-of-humor group today.
If the moderation changes later, I swear, it was "Score:0, Funny" when I posted this.
I've tried several programs that study the source code and tries to find possible null pointers, unchecked input, possibly dirty data and whatnot, and they all have one problem - false detections. When the program studies the source code and gives you the output of this process, you can quickly decide whether to act on it, fixing the potential bug, ignore the problem as "intended behaviour", or simply correct the syntax so the source code studying application doesn't complain about it anymore. However, if you were to run this thing, which is only concerned with the binary, wouldn't it have to run again for every single version of your application you distribute? Also, you'd never actually get any patch information back to put into the source, except maybe in binary... In addition to this, when some programmers take a quick and dirty approach to things to meet deadlines (which are sometimes more important than clean code) how will the program know about your "// DIRTY HACK. WILL FIX LATER, BUT THIS IS NEEDED FOR THE DEMO. FUNCTION X() WILL WORK AS EXPECTED WITH THE TEST DATA" comment in code? Will it try to correct the binary, producing unexpected results?
Hah, we're a long way from finishing code to do text boxes and buttons.
There are many improvements:
1) Write them to work with opengl
2) Write them to scale properly at any DPI
3) Have them fully themable via CSS style sheets
4) Have them stylable with SVG files
5) Adding multi-touch support
Also, the linux kernel has something like 17 seperate linked list implementations, each doing slightly different things :)
"Is not a Bug. Is a Feature"
What can I do If this program starts to delete all my "features"?.
It might help to read the actual paper instead of some hand-waving article.
Here's the pseudo-code:
begin turings_revenge
this_will_crash = find_errors(turings_revenge)
if (this_will_crash)
then
terminate_gracefully();
else
segfault();
end
end
So, will it crash, or won't it?
Martin Rinard, unabashed? I'm shocked, absolutely shocked.
He didn't use a car analogy. Let me help.
"How many times do you have to re-invent the wheel until it's good enough?"
Unless you're complaining about "their" where "there" should be. In that case, carry on.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Just what we need, a license for even MORE sloppy coding techniques...
I once filed a bug report to a developer with instructions on how to reproduce it.
He responded with a fix that involved no changes to the source code.
He said, "don't do that."
I personally disagree with this statement, on the grounds that humans can take programs and determine if they are correct. No one understands exactly how the brain works, but it is clearly very capable of making any calculation a computer could make (albeit at slower speeds), and in that sense it is a computer. Again, no one understands the actual programming, how the mind moves from item to item, but it does often move from sequential thought to sequential thought as a program might. Though different than the computers we have invented ourselves, I think there are enough similarities to say that we work as an enormously complex, self-modifying algorithm, and that particular algorithm can in fact take an arbitrary program and prove correctness. Granted, we aren't born with this ability, and require training (hence the self modifying part), but a properly trained computer scientist/mathemetician will have developed, in his mind, an appropriate algorithm for generally verifying program correctness.
My basic conclusion, then, is that because we know intelligence exists, then it should be possible to construct it (though that is exceedingly hard). In the specific case of proving correctness, though, we may not even need to be a self modifying algorithm, because once someone has learned enough about computer science/math, they have the general tools in their mind to prove correctness, and they need not add any more logical rules. But for sure, as long as desiging a self modifying algorithm is considered fair game, then designing an algorithm that can become capable of proving correctness is possible.
But this whole discussion is actually a moot point, because ClearView doesn't fall (or claim to fall) into the category of determining whether a program is correct. In fact, it doesn't claim to make even a subset of a program correct. It simply replaces specific cases of undesirable behavior with behavior that, while not 100% equivalent, is still less likely to cause major problems. For example, if code has a buffer overflow problem, it is obviously not correct because it can be exploited. If replaced with a fixed length buffer, it won't be equivalent to the original, but the program at least will do nothing more than crash, as opposed to allowing a hacker to gain control of your machine. This is just an exercise in making broken code slightly less dangerous; it's not about proving correctness in any way. And therefore, it is totally possible and outside the scope of the algorithm-that-verifies-correctness problem.
Beware of bugs in the above code; I have only proved it correct, not tried it.
I'm sorry you had to come out of 21-month hibernation to say something so stupid, but you're quite wrong.
You can prove that a given change breaks unit tests, except ... wait for it ... they don't use unit tests. Instead they use their rainbows and unicorns magic heuristics. You can't prove anything without a comprehensive per-application unit test suite, so you might as well just replace all the syscalls with nop stubs. For all you know, that's what this program does. That's why this idea is worthless to industry.
Black box voodoo machine code rewriting without a comprehensive testing is pure madness. No serious company would ever consider doing this; therefore the idea is completely worthless as implemented.
Randomly modifying the a program and then failing to test it is worse than doing nothing. Read the rest of the comment you replied to for the correct way to drop a connection. The suggested method allows for unit testing that includes unexpected failures caught at runtime by the watchdog application.
Interesting use of ClearView in hacker point of view, the program can be patched to not change the binaries, but just to write which places seem vulnerable, and try to attack those vectors of input to gain a zero-day attack on a program which other fuzzers didn't seem to detect those input errors, etc.
Read and Comment at my BLOG
!!!
All fancy language to qualify as a research project, but the authors *really* just want a universalautowarezpatchercracker
Build your own energy sources from scratch. http://otherpower.com/