Fixing Bugs, But Bypassing the Source Code 234
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.
Re:MS will probably kill it (Score:5, Insightful)
If MS included this in Windows, you'd never get to see the login screen because the CPU would be so busy fixing bugs.
clearview (Score:4, Insightful)
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?
Re:MS will probably kill it (Score:1, Insightful)
If MS included this in Windows, you'd never get to see the login screen because the CPU would be so busy fixing bugs.
Geez... imagine the sheer volume of .CONF files a Linux user would have to waft through just to get this to check a distro for bugs.
No Silver Bullet (Score:3, Insightful)
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.
Sensationalism ruined it for me (Score:5, Insightful)
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.
How about (Score:5, Insightful)
Re:Did they use that tool to develop that tool? (Score:5, Insightful)
Fiendish? What could possibly be more fair and objective than making him eat his own dogfood?
Re:Did they use that tool to develop that tool? (Score:3, Insightful)
"Fiendish" prof? If this is even a true story, it rates a "duhh!" Of course he should have ran his analyzer on his own code..
Re:Did they use that tool to develop that tool? (Score:5, Insightful)
Either that or put in an author check that automatically spits out an A+ if it detects that the author of the code was himself....
Re:How about (Score:3, Insightful)
ClearView doesn't have to prove that a program is either correct or incorrect. It only has to detect certain types of bugs, and fix them. There is no guarantee your program is correct after running it.
And personally I can't think of any cases where a buffer overflow is part of a correct program...
Re:MS will probably kill it (Score:4, Insightful)
Me-thinks someone sounds jealous they did not think of it first.
thesis grade? (Score:2, Insightful)
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.
Re:Misleading Slashdot summary, as usual (Score:3, Insightful)
But was it a source patch, or a binary patch? A binary patch is at best a dirty work-around, becuase the bug will keep reappearing in subsequent released of the software (perhaps even in needed patches for other issues).
Re:clearview (Score:4, Insightful)
Really ... they know what they are doing? Then why is it called:
Research
If they knew what they were doing it wouldn't really be research would it.
ALL software has bugs. Adding more software to fix bugs ... introduces more bugs.
This doesn't just apply to software, it applies to just about everything, right down to the atoms that make of the universe from our perspective. As far as we can figure, the universe itself will break down to a state that will no longer support life as we know it. Adding more layers of protection falls under the laws of diminishing returns, software, hardware, bridges, cars, or molecules.
Re:Did they use that tool to develop that tool? (Score:2, Insightful)
It will basically find average the number of lines per function, ratio of code to comment, and other such metrics and give a letter grade to the code.
int is_equal(int a, int b) {
if ((a = b)) {
return 1;
}
return 0;
}
Do I get an A?
Re:Did they use that tool to develop that tool? (Score:3, Insightful)
Being graded on the quality of the ideas in the thesis and not the implementation?
Why even implement then? Just write a paper and be done with it.
In other words, if the MSc thesis requirements include an implementation then clearly the quality of the implementation is going to be evaluated.
If that guy ever gets a real job outside of academia the lesson he learned from that singular experience will probably define his career.
Re:How about (Score:5, Insightful)
Except that you are making two mistakes:
- the Entscheidungsproblem refers to the problem of finding a general solution that will determine for all possible programs whether or not they are correct. This is an undecidable problem. However, this does NOT mean you can't find a solution for certain subclasses of programs, or a program that finds certain kinds of flaws.
- also, you already know there is an error (otherwise the program wouldn't be triggered), and the type of error (e.g. NULL pointer, array index out of bounds etc.) . That makes much easier again than the general Entscheidungsproblem.
Re:How about (Score:4, Insightful)
Your claim to expertise is having read a single popular book, but you can't spot the common error of claiming because a general solution can't exist, no specific solution can exist?
Re:How about (Score:4, Insightful)
Car analogy - Clearview isn't figuring out whether the whole car is perfect (in the real world it's 100% likely to be imperfect anyway ;) ), all it does is help detect and fix the holes in the exterior.
I ran this program on my car and all was good until I went to fill up the gas tank. Bloody hell, Clearview got rid of the gas tank orifice!
Re:Why owuld you need to access the source (Score:3, Insightful)
paff. People have been doing this with SuperZap on mainframe code for 30 years. Kids.
Now get off my lawn.
Re:I sure wouldn't (Score:2, Insightful)
That would obviously bring SkyNet into existence!
Re:How about (Score:3, Insightful)
Even if the modified program fails to crash and fails to trigger the anomaly detector, there's no way to prove that the program still works as intended. For example, suppose the fix of an overflow also elides the initialization of some other variable, which results in data corruption? How is that better than an overflow/crash?
The approach is valuable even if you can't prove the program still works as intended (which is impossible in general). The goal is to have a program that works a bit better than it would without ClearView.
For example, the unmodified web server may have a buffer overflow that can lead to the system being hijacked. ClearView modifies the program so that a connection is prematurely dropped, but hijacking is prevented. Neither behavior was what was the programmer intended, but we've taken a serious bug and replaced it with a minor bug. That's valuable.
The real issue is whether the modifications do in fact make the program work a bit better. Rinard's experiments indicate that they do, at least for the applications used in the experiments.
Re:How about (Score:3, Insightful)
You (perhaps) joke, but this is a real problem. In context, a bug in one program would be a feature in another...
This is a trivial example, but imagine a program designed to segfault: int main() { char* p=0; char x=*p; }.
How do you fix this? What's correct? Do you assign p to a safe value? If so, what? Do you simply remove the assignment of x? What about anything downstream that uses x? What if you wanted it to crash? What if p was assigned by a function (scanf)? What should it be?
Without knowing the purpose, intent, and processes of the program, this simple bug is unfixable. A human could say "I meant to assign p" or "scanf shouldn't be giving me null..." or even adding a conditional that spits out an error message and continues.
In a sense, these programs fail because their behavior is undefined. And it's undefined for a reason - there's many states it could be, and one it should be, and it's not matching up.