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.
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.
You can't write an algorithm that takes as input another algorithm and outputs whether that second algorithm is correct or not. Since ClearView must make this decision somehow (this behavior is bad; make it good), the process cannot be algorithmic. However-- this is exactly how the vast majority of software is written now-- a programmer has a good idea about how to solve the problem, but does not "provably" solve it. If you believe language designers, that's part of the problem. ClearView just adds another layer of heuristics on top of the ones that are already there. Someone has to come up with those rules. This makes the actual work of understanding a program much more complicated. But, you know, the MIT people have been chasing AI for a long time, so maybe they don't think that understanding something is important as long as there's a good simulacrum of the thing they're trying to create. Black box computer science.
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...
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
- 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.
Clearview doesn't have to figure out whether the entire program is correct. It just tries to fix what's known to be incorrect (and presumably whether it falls into the subset of bugs it knows how to fix).
The sort of "correctness" and "incorrectness" for many security problems are typically "stupid mistakes" nothing very sophisticated.
You're taking too much of the "Ivory Tower Computer Science" view on this. 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. It doesn't have to perfectly fix stuff.
FWIW I've already manually fixed programs without having the source, and managed to get a program to do stuff the manufacturer said the program can't do;). I've also fixed a TCL program stored in an oracle database by hexediting the oracle DB file, but since that was TCL it doesn't count as "without the source"...
Just because you can't make it perfect doesn't mean you can't make it work better.
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!
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?
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?
Now that the whole Chuck Norris phase has kinda spun down does anyone see Bruce Schneier picking up the mantel? At least in geek culture / IT? I think it would be hilarious.
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.
It's not really very nice. If the testing of the patched software is purely automated, I wouldn't reckon its chances highly of managing a fix without screwing something else up except in very simple systems or very well coded and sensibly designed systems.
They say this is intended as a method for keeping crap old code going when the original vendors are gone. Odds are, this autopatcher is going to be dealing with stuff the like of which you'd expect to see on thedailywtf.
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).
Look at the hex, make changes. The conept is no different then inserting or replacing a JMP to get around software protection.
Exactly! This software sounds like it might work for getting around non-technical vendor-imposed arbitrary limitations.
If you don't feel like paying for the Standard Edition of SQL Server 2005 anymore, now you won't have to, you can just purchase the slightly crippled Workgroup edition, and have ClearView make sure the database keeps on running after it blows by its self-imposed limits. Don't have legal copies of Windows 7, that's ok. Now your government or your office will have a contingency plan, should
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.
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?
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.
My friend developed an automatic code quality estimation program for his masters thesis. 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. The fiendish prof announced that he will run that code through itself. Whatever letter grade it spits out will be his thesis grade. He got a D. He begged and cried and threw a hissy fit and wangled a B and scraped through the degree.
I wonder if we should turn that software loose on itself and see what it finds.
The fiendish prof announced that he will run that code through itself. Whatever letter grade it spits out will be his thesis grade. He got a D. He begged and cried and threw a hissy fit and wangled a B and scraped through the degree.
Fiendish? What could possibly be more fair and objective than making him eat his own dogfood?
"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, according to a report issued by security company Symantec in 2006."
This is absolutely correct, so long as one assumes that Windows systems are the only systems, and Linux developers aren't human.
The fact that they care far less about backwards compatibility ABI since most things for Linux can be recompiled might have a slight effect on why Linux bugs get 'fixed' faster. You have a different definition of 'fix' than most of the world.
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.
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.
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...
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:)
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.
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.
501:~ $ locate.CONF 502:~ $
Looks like the volume is...zero? I think maybe I don't understand what you mean. Is ".CONF" some sort of Windows-speak for configuration files? If so, then the fact that they're all in/etc (or possibly/usr/etc or/usr/local/etc) and/home should make them very easy to skip.
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.
Is this some sort of "out-stereotype the operating system" competition? If so, here is my entry:
If the tool from TFA existed already, Mac users wouldn't notice it until Steve Jobs named it the iPatcher and made some cutesy advertisements with Justin Long wearing an eye patch. At that point they'd proclaim it made their systems invulnerable to bugs in a far superior way than Windows and Linux.
I sure wouldn't (Score:5, Funny)
run this software before running ClearView on it first. Imagine what this could do if it had a bug in its code!
Re: (Score:3, Funny)
Error - Stack recursion. Head asploding!
This really deserves (Score:5, Funny)
How about (Score:5, Insightful)
Parent
Re:How about (Score:4, Interesting)
Parent
Re: (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: (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
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.
Parent
Re:How about (Score:5, Interesting)
The sort of "correctness" and "incorrectness" for many security problems are typically "stupid mistakes" nothing very sophisticated.
You're taking too much of the "Ivory Tower Computer Science" view on this. 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
FWIW I've already manually fixed programs without having the source, and managed to get a program to do stuff the manufacturer said the program can't do
Just because you can't make it perfect doesn't mean you can't make it work better.
Parent
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!
Parent
Re: (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 purpos
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?
Parent
Re:How about (Score:4, Funny)
Bruce Schneier is the general solution.
Parent
Re: (Score:3, Informative)
Now that the whole Chuck Norris phase has kinda spun down does anyone see Bruce Schneier picking up the mantel? At least in geek culture / IT? I think it would be hilarious.
Ask and ye shall receive [schneierfacts.com].
...an immortal, invulnerable program... (Score:5, Funny)
Has anyone cracked "Hello World" yet?
Re: (Score:3, Funny)
It's not immortal. You want:
while 1:
print "Hello World"
Re: (Score:3, Funny)
These two posts contain the most robust code I've seen all day. But still,
"A computer's attention span is no longer than it's power cord."
Source doesn't run (Score:2)
Misleading Slashdot summary, as usual (Score:2, Informative)
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.
Re: (Score:2)
They say this is intended as a method for keeping crap old code going when the original vendors are gone. Odds are, this autopatcher is going to be dealing with stuff the like of which you'd expect to see on thedailywtf.
Re: (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).
Why owuld you need to access the source (Score:2)
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.
Re: (Score:3, Interesting)
Look at the hex, make changes. The conept is no different then inserting or replacing a JMP to get around software protection.
Exactly! This software sounds like it might work for getting around non-technical vendor-imposed arbitrary limitations.
If you don't feel like paying for the Standard Edition of SQL Server 2005 anymore, now you won't have to, you can just purchase the slightly crippled Workgroup edition, and have ClearView make sure the database keeps on running after it blows by its self-imposed limits. Don't have legal copies of Windows 7, that's ok. Now your government or your office will have a contingency plan, should
Re: (Score:3, Insightful)
paff. People have been doing this with SuperZap on mainframe code for 30 years. Kids.
Now get off my lawn.
If humans did the same..! (Score:5, Funny)
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 police the police? (Score:2, Interesting)
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:clearview (Score:5, Funny)
So run two.
Parent
Re:clearview (Score:4, Interesting)
id1: Friar Tuck... I am under attack! Pray save me!
id1: Off (aborted)
id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men!
id1: Thank you, my good fellow!
http://catb.org/jargon/html/meaning-of-hack.html [catb.org]
Parent
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.
Parent
Did they use that tool to develop that tool? (Score:5, Interesting)
I wonder if we should turn that software loose on itself and see what it finds.
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?
Parent
Re: (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: (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....
Parent
Obviously Linux developers aren't human ;-) (Score:3, Interesting)
This is absolutely correct, so long as one assumes that Windows systems are the only systems, and Linux developers aren't human.
Re: (Score:3, Interesting)
The fact that they care far less about backwards compatibility ABI since most things for Linux can be recompiled might have a slight effect on why Linux bugs get 'fixed' faster. You have a different definition of 'fix' than most of the world.
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.
Re: (Score:3, Informative)
I'd also point out, that from an Automata Theory standpoint, "The task of software verification is not solvable by a computer" (MIT's own Sipser).
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.
sensasionalists ? (Score:4, Informative)
The actual paper. (Score:3, Informative)
Fixing bugs without accessing source code (Score:3, Interesting)
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."
Re:It's interesting, but software should "expire". (Score:4, Funny)
This doesn't support innovation and improvement, and that's the cornerstone of technology improvement.
Please allow myself to introduce... myself.
Parent
Re: (Score:3, Interesting)
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 :)
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.
Parent
Yeah, and if it did happen to work (Score:2)
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.
.
Re:MS will probably kill it (Score:5, Informative)
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.
Looks like the volume is...zero? I think maybe I don't understand what you mean. Is ".CONF" some sort of Windows-speak for configuration files? If so, then the fact that they're all in /etc (or possibly /usr/etc or /usr/local/etc) and /home should make them very easy to skip.
Parent
Re:MS will probably kill it (Score:5, Funny)
Is this some sort of "out-stereotype the operating system" competition? If so, here is my entry:
If the tool from TFA existed already, Mac users wouldn't notice it until Steve Jobs named it the iPatcher and made some cutesy advertisements with Justin Long wearing an eye patch. At that point they'd proclaim it made their systems invulnerable to bugs in a far superior way than Windows and Linux.
Parent
Re:MS will probably kill it (Score:4, Insightful)
Me-thinks someone sounds jealous they did not think of it first.
Parent