Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software Bug Science Technology

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.
This discussion has been archived. No new comments can be posted.

Fixing Bugs, But Bypassing the Source Code

Comments Filter:
  • by Korbeau ( 913903 ) on Thursday October 29, 2009 @07:06PM (#29918067)

    run this software before running ClearView on it first. Imagine what this could do if it had a bug in its code!

  • by fuzzyfuzzyfungus ( 1223518 ) on Thursday October 29, 2009 @07:09PM (#29918091) Journal
    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.
    • How about (Score:5, Insightful)

      by raddan ( 519638 ) * on Thursday October 29, 2009 @08:02PM (#29918583)
      "Entscheidungsproblem [wikipedia.org]". You'd think a professor of CS at MIT would have heard of it.
      • by blueg3 ( 192743 )

        The relevance here?

        • Re:How about (Score:4, Interesting)

          by raddan ( 519638 ) * on Thursday October 29, 2009 @08:49PM (#29919137)
          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.
          • Re: (Score:3, Insightful)

            by Migala77 ( 1179151 )

            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:How about (Score:5, Insightful)

            by eggnoglatte ( 1047660 ) on Thursday October 29, 2009 @10:36PM (#29919969)

            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:5, Interesting)

            by TheLink ( 130905 ) on Thursday October 29, 2009 @11:17PM (#29920227) Journal
            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.
            • Re:How about (Score:4, Insightful)

              by marciot ( 598356 ) on Thursday October 29, 2009 @11:51PM (#29920411)

              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: (Score:3, Insightful)

                by slimjim8094 ( 941042 )

                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

            • The first program ClearView runs on will no longer have any obvious bugs, but it will still have all it's subtle bugs, and it will have all the subtle bugs introduced by ClearView's fixes

              Yes my car now has no rust spots and the windscreen has no chips in it but the steering wheel is now square, It changes from first gear to second via reverse, and the ignition does not work when I use my key ....

          • That's why for heart-lung machines and other "mission critical" stuff with guarantees, people write their code in Haskell, and do real mathematical proofs for it. There are also tools to automatically generate those proofs from some annotations. But for most code, it simply isn't necessary to be that ultra-verbose.

      • Isn't that the one that Bruce Schneier has the general solution to?
  • by John Hasler ( 414242 ) on Thursday October 29, 2009 @07:11PM (#29918111) Homepage

    Has anyone cracked "Hello World" yet?

    • Re: (Score:3, Funny)

      by selven ( 1556643 )

      It's not immortal. You want:

      while 1:
              print "Hello World"

      • It's not immortal. You want:

        while 1:
                        print "Hello World"

        Sorry, but I have prior art on a truly immortal and bug-free program:

        10 PRINT "HELLO WORLD"
        20 GOTO 10

        Let me know who I should contact so MIT can send the royalty checks on my software patent to me.

    • by syousef ( 465911 )

      Has anyone cracked "Hello World" yet?

      I think someone cracked my "Hello World". It compiled fine but when I ran it, it printed out "Core Dumped".

  • 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.
    • Yes, it sounds like a dumb idea. Sure, you can look for certain simple things in running or compiled code, but you can't debug much more complicated things without access to the source, unless perhaps this checking program were orders of magnitude more complicated than the code it's checking. Why bother, when you can just get the source?

      It's like trying to make some kind of "scanner" which can detect faults in a building's design, without even going inside the building, (which obviously would require a lo

      • by lgw ( 121541 )

        There's a lot of code optimization, for example, that works better with object code (or some platform-independent intermediate code or bytecode) than with source code, by doing template matching. The source code may give hints about the user's intentions, which is useful for some kinds of problem solving. The object code give information about patterns that are common regardless of intention, which is useful for other kinds of problem solving. I've found the latter to be quite useful in debugging difficu

      • by ceoyoyo ( 59147 )

        A person needs source code to effectively check things. A program doesn't. Source code isn't magic, it's just set up to be nice for a person to read. It's crap for a machine to read though, which is why pure interpreters are so slow.

      • by Korin43 ( 881732 )
        It makes sense to me that a program wouldn't need the source code to detect errors. Source code is just a way for humans to understand computer programs, there's no reason computers would find source code easier to work with. Especially if it's the sort of find/replace deal that it sounds like.
  • by Anonymous Coward

    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.

    • 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.
    • Re: (Score:2, Informative)

      by Meshach ( 578918 )
      The program does not really "fix software bugs" at all. What it does is notice if a program starts taking an abnormal code path. The "normality" of a path is based on how the program operates. If a program starts taking an abnormal path then it is terminated.

      This is good in preventing an attack or code injection. But as far as bug fixing nothing could be further from the truth. Some developer still needs to look at the assembly generated to identify the bad path taken, find that place in the code, fi
      • by lgw ( 121541 )

        Well, obviously a valuable tool for finding bugs is a valuable tool for improving software. But perhaps not by itself.

  • 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)

      by stephanruby ( 542433 )

      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.

  • by Odinlake ( 1057938 ) on Thursday October 29, 2009 @07:18PM (#29918185)

    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.

    • by Xtravar ( 725372 )

      THIS IS UNNATURAL HERESY!!!!
      You've convinced me. We need to destroy this program and replace it with one that makes judgments based on feelings.

  • Who will fix the bugs in the ClearView program?
  • clearview (Score:4, Insightful)

    by wizardforce ( 1005805 ) on Thursday October 29, 2009 @07:22PM (#29918219) Journal

    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?

    • by Anonymous Coward on Thursday October 29, 2009 @07:33PM (#29918327)

      So run two.

    • Why attack the programs it is patching when you could hit Clearview and gain the ability to hijack everything it is patching?

      Because hopefully you're running Clearview in your development environment, not a production one.

  • by 140Mandak262Jamuna ( 970587 ) on Thursday October 29, 2009 @07:32PM (#29918311) Journal
    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.

    • by Wonko the Sane ( 25252 ) * on Thursday October 29, 2009 @08:19PM (#29918795) Journal

      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?

      • 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?

        Suggesting that he runs his prof's code through the analyzer, if the prof truly believes his code deserves a "D"...

    • Re: (Score:3, Insightful)

      by mattack2 ( 1165421 )

      "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..

    • thesis grade? (Score:2, Insightful)

      by pigwiggle ( 882643 )

      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.

    • Great story, but [Citation needed].

    • More appropriate would be to give your friend a F as he seems to have entirely missed the point. If he had a clue, he would have added a check to itself to always give itself an A, maybe throw in a joke about it along the way.

      He didn't deserve a D, that much is clear.

    • Re: (Score:2, Insightful)

      by Mike610544 ( 578872 )

      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.

      //
      // Are
      // two
      // numbers
      // equal?
      //
      int is_equal(int a, int b) {
      if ((a = b)) {
      return 1;
      }
      return 0;
      }
      // This
      // function
      // only
      // takes
      // up
      // 6
      // lines

      Do I get an A?

    • Dude deserves to fail: when confronted, he shoulda countered that he used his program as a baseline: the program that minimally gets a "pass", when run through the analyzer. Any MS student who can't BS his thesis prof... *sigh*...!

    • The fiendish prof announced that he will run that code through itself. Whatever letter grade it spits out will be his thesis grade.

      The even more fiendish student submits the following code:
      int main(int argc, char **argv)
      {
      printf("A\n");
      }
      Of course, with lots of fluff around it to make it less obvious...

  • by Zero__Kelvin ( 151819 ) on Thursday October 29, 2009 @07:32PM (#29918313) Homepage

    "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.

    • Re: (Score:3, Interesting)

      by BitZtream ( 692029 )

      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)

    by gweihir ( 88907 ) on Thursday October 29, 2009 @07:52PM (#29918487)

    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)

      by Yold ( 473518 )

      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).

      • Yeah, their headlines are pure sensationalism. And if I'm not mistaken what your saying is actually demonstrable.
  • by billcopc ( 196330 ) <vrillco@yahoo.com> on Thursday October 29, 2009 @07:52PM (#29918493) Homepage

    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.

    • 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 qui

  • terrible name. Come on ClearView is the best you could come up with?
  • sensasionalists ? (Score:4, Informative)

    by cameigons ( 1617181 ) on Thursday October 29, 2009 @08:14PM (#29918749)
    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...
  • Be skeptical (Score:2, Interesting)

    by Anonymous Coward

    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.

    • by DarkOx ( 621550 )

      I can image clearview being able to fix some of those problems.

      Oh the "stacks been smashed" -> let me I usually see a code that looks like a pointer dereference called and then a fetch of between 5 and 67 bytes
      ->This time it was 643 bytes!
      ->I will just stick a jump in there and save off the stack and write some code to copy not more than 67 bytes which from past experience is safe from location A to location B and then put the stack back and set the program counter to the address after the jump I i

  • 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.)

  • http://en.wikipedia.org/wiki/Rice's_theorem [wikipedia.org]

    Can I get my star now?

    People this is what we get when people grow up with Windows.

  • 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

  • From TFA:

    By observing a program's normal behavior and assigning a set of rules, ClearView detects certain types of errors, particularly those caused when an attacker injects malicious input into a program. 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 a

  • 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 thi

  • "Is not a Bug. Is a Feature"
    What can I do If this program starts to delete all my "features"?.

  • The actual paper. (Score:3, Informative)

    by ROBOKATZ ( 211768 ) on Friday October 30, 2009 @08:13AM (#29922339)
    It might help to read the actual paper [mit.edu] 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?

  • by cryptor3 ( 572787 ) on Friday October 30, 2009 @11:13PM (#29931785) Journal

    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."

"If it ain't broke, don't fix it." - Bert Lantz

Working...