Slashdot Mirror

← Back to Stories (view on slashdot.org)

Researchers Add Software Bugs To Reduce the Number of Software Bugs (networkworld.com)

Posted by msmash on from the innovative-techniques dept.

Reader alphadogg writes: Researchers are adding bugs to experimental software code in order to ultimately wind up with programs that have fewer vulnerabilities. The idea is to insert a known quantity of vulnerabilities into code, then see how many of them are discovered by bug-finding tools. By analyzing the reasons bugs escape detection, developers can create more effective bug-finders, according to researchers at New York University in collaboration with others from MIT's Lincoln Laboratory and Northeastern University. They created large-scale automated vulnerability addition (LAVA), which is a low-cost technique that adds the vulnerabilities."The only way to evaluate a bug finder is to control the number of bugs in a program, which is exactly what we do with LAVA," says Brendan Dolan-Gavitt, a computer science and engineering professor at NYU's Tandon School of Engineering.

73 comments

  1. This is NOT a new thing. by sconeu · · Score: 4, Interesting

    The practice is known as "bug farming", and has been around since at least the mid-80s.

    I learned it when I was in college in '84.

    --
    General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    1. Re:This is NOT a new thing. by The-Ixian · · Score: 1, Redundant

      Actually, is there anything that can be considered "new"?

      Everything is just a rehash of stuff we have done before.

      You might say that technology is new... but is it really? Technology is just a different way of doing the same old things like communicating with each other and building communities.

      All "new" ideas are really just reboots of old ideas.

      --
      My eyes reflect the stars and a smile lights up my face.
    2. Re:This is NOT a new thing. by GrumpySteen · · Score: 1

      You might say that technology is new... but is it really? Technology is just a different way of doing the same old things like communicating with each other and building communities.

      If you're going to get ridiculously reductive, then nothing new has shown up since the time very shortly after the big bang when the different forces separated and the laws of physics as we know them took hold (assuming those theories are even close to correct). Everything since then has just been different ways of combining the same old subatomic particles.

    3. Re:This is NOT a new thing. by Anonymous Coward · · Score: 0

      Hell, if it's a deterministic universe, then time is just an illusion and everything that is going to happen has technically already happened. Nothing *can* be new. Everything just *is.*

    4. Re:This is NOT a new thing. by sconeu · · Score: 1

      Time is an illusion. Lunchtime doubly so.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    5. Re:This is NOT a new thing. by Anonymous Coward · · Score: 0

      People assume that time is a strict progression from cause to effect, but actually from a non-linear, non-subjective viewpoint, it's more like a big ball of wibbly-wobbly timey-wimey ... stuff.

    6. Re:This is NOT a new thing. by Anonymous Coward · · Score: 0

      Academic research papers often do not explore radically new ideas, but instead build upon, refine, or optimize them. I'm sure you did use this idea a long time ago, but was your technique as good what's presented in this new paper?

    7. Re:This is NOT a new thing. by Anonymous Coward · · Score: 0

      I tried to look up more about this, but all I'm finding is stuff about edible insects.
      Could you show me some articles or the like about (software) bug farming?

    8. Re:This is NOT a new thing. by sconeu · · Score: 1

      Apparently that was the name our quality metrics guys used.

      Look for "Defect Injection" instead.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    9. Re:This is NOT a new thing. by porges · · Score: 1

      I learned as "bug seeding", but yes, and I'm of about the same vintage as you.

    10. Re: This is NOT a new thing. by Anonymous Coward · · Score: 0

      I haven't heard the phrase bug farming, but what this article describes is a kind of mutation testing (https://en.m.wikipedia.org/wiki/Mutation_testing).

      You introduce mutations into your software to see if your test suite catches them.

      If you can mutate your software and it still passes the entire test suite, then your tests aren't sound. (Or, the mutation didn't actually break the software)

    11. Re:This is NOT a new thing. by hsweeney · · Score: 1

      > The idea is to insert a known quantity of vulnerabilities into code, then see how many of them are discovered by bug-finding tools.

      I heard that called "bebugging" in the 70s. Still seems like a good idea.

    12. Re:This is NOT a new thing. by Capt.Albatross · · Score: 1

      All "new" ideas are really just reboots of old ideas.

      You are just repeating one of Herodotus' tweets.

  2. Won't Help Much by sexconker · · Score: 1

    Knowns
    Known Unknowns
    Unknown Unknowns

    You can't train your test for Unknown Unknowns. At best you can heuristically catch Known Unknowns. And Knowns are already Known, you just need to make sure your tools catch them.

    1. Re:Won't Help Much by Anonymous Coward · · Score: 0

      Don't forget the Unknown Knowns....

    2. Re:Won't Help Much by gurps_npc · · Score: 2

      I always hated that that quote ignores the unknown knowns. (Things we know, but don't know we know) They are often the most important things - and things we don't write down until after someone asks us "how did you do that?"

      --
      excitingthingstodo.blogspot.com
    3. Re:Won't Help Much by Anonymous Coward · · Score: 0

      And the known knowns.

    4. Re:Won't Help Much by Sax+Russell+5449D29A · · Score: 1

      Dick Cheney taught us all about the unknown unknowns.

      --
      -SR
    5. Re:Won't Help Much by Sax+Russell+5449D29A · · Score: 1

      *Donald Rumsfeld :-|

      --
      -SR
    6. Re:Won't Help Much by jellomizer · · Score: 1

      Well what constitutes a bug?
      I am guessing this catches those compile errors or buffer overflow issues. However the most bugs I experience is due to miscommunication of the requirement.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    7. Re:Won't Help Much by UnknownSoldier · · Score: 2

      You're looking for this picture ... "Ignorance Map"
      https://lh3.googleusercontent....

      * Known Unknowns -- All the things you you know you don't know
      * Unknown Unknowns -- All the things you don't know you don't know
      * Errors -- All the things you think you know but don't
      * Unknown Knowns -- All the things you don't know you know
      * Taboos -- Dangerous, polluting or forbidden knowledge
      * Denials -- All the things too painful to know, so you don't

      Ironically, it is missing the most important part:

      * Known Knowns -- Everything you know (either by proof or experience)

      --
      Fix the broken political system -- POOL all political donations and then evenly divide them every quarter to every active party.

    8. Re:Won't Help Much by Archangel+Michael · · Score: 1

      My view of bugs are that the requirements are known, but are changed along the way, so how you deal with the original requirement isn't necessarily how you deal with the new, improved requirement, and trying to not have to rewrite the entire codebase simply to adjust for the whims of a project manager. It is this "miscommunication" that causes the greatest bugs in my experience.

      A radio button is not a check box. Designing for one, and having to switch to another, without having to rewrite the surrounding code is nearly impossible. And when you rewrite one part of the code, it has unexpected consequences to the other bits that also depend on it. (lame example, I know, but it gets my point across)

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    9. Re:Won't Help Much by ShanghaiBill · · Score: 1

      I always hated that that quote ignores the unknown knowns. (Things we know, but don't know we know)

      It also ignores the known unknowns (Things we think we know, but actually don't). Don Rumsfeld famously used this quote, and he "knew" that Iraq had WMDs. He also "knew" that Iraqis would greet us as liberators, throw flowers at our feet, and would be grateful as we spread peace and prosperity across their land. Those things were not in doubt.

    10. Re: Won't Help Much by Anonymous Coward · · Score: 0

      I always forget about those!

    11. Re:Won't Help Much by Anonymous Coward · · Score: 0

      ‘Ironically, it is missing the most important part:’ – How is that ironic? It's an map of ignorance. It's like saying it's ironic that France isn't on a map of England.

    12. Re: Won't Help Much by Anonymous Coward · · Score: 0

      That solution would be hilarious. The shared collectivism of the idea would probably turn off most people from donating large sums. Sort of a self loathing answer to the problem. We deserve it.

    13. Re:Won't Help Much by sexconker · · Score: 1

      It's not a lame example, It's a perfect example.

      Using a radio button means you want a max of 1 choice, yet 3 months down the line they'll change their mind and say they want to allow for multiple choices. You then have to decide on the default state for each checkbox like you decided on what the default radio button was. Then you have to change your database to store a flag for each checkbox instead of a value that has a relationship to a primary key table. And you have to decide on whether or not NULL is a valid, third state depending on what parts of what forms were completed. Then you have to decide on a default 1 or 0 or NULL.

      Then it's a pain in the ass when they add and remove checkboxes because you have to generate forms based on which checkboxes were active on which dates, allow admins to override and see all the checkboxes regardless of date so they can go and retroactively fix old forms, etc. So you need a table for your checkboxes, their displayed names, and their valid dates, then a table for the order they should appear in for each date any change is made, a table to dynamically track the checkbox values for each form, etc.

      And it has to be done yesterday because that's when the policy was signed. And you found out about it from a 3rd-party user because your actual customers you built the thing for don't communicate shit to you and don't understand their own business rules.

      Everything has to be designed such that anything can happen at any time, because it will.

    14. Re: Won't Help Much by Anonymous Coward · · Score: 0

      Gotta catch 'em all.

      http://cdn.bulbagarden.net/upload/thumb/7/77/201Unown.png/250px-201Unown.png

  3. Old hat by Anonymous Coward · · Score: 0

    Bell Labs (and its successor companies) have been doing this since the 1960s.

    1. Re:Old hat by ls671 · · Score: 1

      Roman army has been doing this since 450 B.C.

      --
      Everything I write is lies, read between the lines.
  4. Hmm... by Anonymous Coward · · Score: 0

    I never worked at a place where the ONLY DOCUMENTATION available is a list of bugs. Hmm...

  5. Unit Testing by darkain · · Score: 4, Insightful

    So wait, what you're telling me is that someone just finally discovered that it is a good idea to unit test the unit testing tools!?

    1. Re:Unit Testing by Zero__Kelvin · · Score: 1

      You are right that they are unit tests. You are wrong when you classify the software under test as unit testing tools. What is just slightly different here is that the unit tests are not developed by the developers of the tools. Somebody is doing 3rd party unit tests of code analysis tools.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  6. So by Anonymous Coward · · Score: 0

    This pretty much explains the Facebook app on Android. It's full of bugs, and every release they add more bugs... apparently hoping it'll make the other bugs go away

  7. CS Reseach by 110010001000 · · Score: 1

    So this is what Computer Science research has come to? How would you test bug finding software without introducing known bugs to the programs under test? Magic?

    1. Re:CS Reseach by godrik · · Score: 2

      Please do not judge CS researcher by a single paper. BTW, this paper was not even the best paper at IEEE SP. (complete list with best papers at [1].)

      From a quick read of the lava paper. It seems that the novelty aspect of LAVA is that the software can inject bugs automatically in complex codebase. So you no longer have a grad student writing obviously faulty code on a toy program or inserting a few bugs manually to test one or two software. LAVA allows you to insert a myriad of bug in a myriad of software to test border condition more accurately.

      Clearly it is not the best idea of the decade, but it is a nice little tool/result.

      [1] http://www.ieee-security.org/T...

    2. Re:CS Reseach by Anonymous Coward · · Score: 0

      Just assume that all software has bugs in it. If your bug finding software doesn't find any, it's buggy -- and you may want to run it against itself. ;)

  8. None or Almost none by Anonymous Coward · · Score: 0

    No need for much research... especially if code is in a modern language like C# or Java

  9. How to test your Anti-Virus Software by Anonymous Coward · · Score: 0

    X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

    Or you could test your anti-virus software by visiting dodgy web sites....

    1. Re:How to test your Anti-Virus Software by Anonymous Coward · · Score: 0

      X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

      Not all of are good at calculus

  10. Researchers invent novel new form of research... by PCM2 · · Score: 1

    ...that leverages the actual practice of research. Read all about it.

    --
    Breakfast served all day!
  11. Only useful if real-world bugs are included by Tony+Isaac · · Score: 1

    Artificially introduced bugs are too predictable and contrived. "I'll introduce a buffer overrun error here." Fine. But unless the algorithm can also find real-world buffer overruns, it's not worth much. In real world bugs, the bug is often not obvious to a casual observer, as it would be with an artificially introduced bug.

    1. Re:Only useful if real-world bugs are included by mysidia · · Score: 1

      You need a parallel experiment, where you have a team of HUMANS who are given the task to introduce sneaky security bugs into the software that allow arbitrary code execution, encryption key exposure, Or accidentally leak other data over the network but are hard to detect and won't show up in unit tests.

      You announce that there will be monetary compensation for the authors of the 10 bugs in each category that survive the largest number of code reviews.

    2. Re:Only useful if real-world bugs are included by ale2011 · · Score: 1

      You announce that there will be monetary compensation for the authors of the 10 bugs in each category that survive the largest number of code reviews.

      So you have categorized bugs already, well done! That way you can prevent claims based on submissions that you don't consider bugs.
      —
      Of course it's a bug, otherwise it would have been documented!

    3. Re:Only useful if real-world bugs are included by Zero__Kelvin · · Score: 1

      "Artificially introduced bugs are too predictable and contrived."

      Actually, it is the predictable and contrived nature that makes them useful. How else do you propose to prove that a tool can catch a bug of a particular type than actually designing such a bug of said type? You seem to think they are saying: "Hey, once we've done this, that's everything! Our unit tests cover every possible scenario!" You are like they guy who argues: "Testing is useless because it won't catch every possible problem, so why bother! I'll know there is a problem when the customer calls!"

      " In real world bugs, the bug is often not obvious to a casual observer, as it would be with an artificially introduced bug."

      That would be an excellent point if the person designing the bugs was a casual observer rather than an expert in their field. You do know that most people who write software aren't experts in their field with an intimate knowledge of the underlying mechanisms and potential misunderstandings of the language, right?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    4. Re:Only useful if real-world bugs are included by Tony+Isaac · · Score: 1

      How else do you propose to prove that a tool can catch a bug of a particular type

      I'd analyze commits to actual living systems, looking for fixes made to correct bugs that were found "in the wild." I'd then test the system against the previous version of the code in which the bugs weren't yet fixed, and see if the system could catch them.

      By "casual observer," I was assuming that the observer would be proficient in programming.

  12. Was going to say the same about Firefox by xxxJonBoyxxx · · Score: 1

    Was going to say the same about Firefox...I thought I finally figured out their plan.

  13. what about having real qa & not endusers / cod by Joe_Dragon · · Score: 1

    what about having real qa & not end users and your own coders be the testes?

    And the QA needs to have the rights / means to change settings and set up the environment in different ways to test out different things. Helps to have people with a QA / testing mind set there.

    For some things changes how things work from an standard / the way it has been for a long time to a new default can seem like an bug / lead to bad stuff happening. Like the Gear shift confusion issue that can kill people where was QA on that one? Or did the designers thing that the old way needed to change and did not take testing in put?

    https://consumerist.com/2016/0...

    http://money.cnn.com/2016/04/2...

    http://www.roadandtrack.com/ne...

  14. Say what? by nvm_my_comment · · Score: 1

    Title is really misleading...

  15. Been there, done that... by __aaclcg7560 · · Score: 1

    My first day as a video game tester, I was told find bugs in a newly released video game for the PC. I expected to find none, as I naively assumed no one would knowingly ship a product with bugs. By the end of the day, I presented the bugs found. I found every bug that the game shipped with, including a hard-to-reproduce crashed bug. When I later became a lead video game, I fought battles with the developers to ship bug free products and got overruled every time. Their bonuses were dependent on the game being shipped on time (which wasn't the case most of the time). They didn't care.

    1. Re:Been there, done that... by Anonymous Coward · · Score: 0

      Wow, that's fantastic. Not only did you find EVERY BUG, but then you became the lead video game! Not only that, but they hired a whole team of testers and then ignored each and every one of the team's findings. All of this is highly believable. Thanks for sharing!

    2. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      I became a lead video game tester, but that came three years later.

    3. Re:Been there, done that... by 110010001000 · · Score: 1

      I would overrule you too. There is no such thing as a bug free product of any complexity.

    4. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      I would overrule you too.

      A fellow lead tester got overruled on a last minute crash bug for code release. Developers were unable to reproduce the crash, and, since their bonus was on the line, got management to approve for release. Turned out that the executable file got infected with a virus when the developer zipped up the files for the ftp server, which caused the video game to crash after being burned to a CD. A quarter-million CDs got trashed when management learned that the CD master still had the virus. Not something you want to ship in a PC product. The developer had to give up all their past and future bonuses.

      There is no such thing as a bug free product of any complexity.

      Another developer guessed the login/password for the bug database, marked all their bugs as fixed (including a half-dozen crash bugs), and, since their bonus was on the line, demanded that the game code release immediately. The QA team spent six weeks re-testing all 3,000+ bugs to determine which bugs were still valid — and found quite a few more — that the developer had to fix before the game code release. The developer had to give up all their past and future bonuses.

    5. Re:Been there, done that... by Zero__Kelvin · · Score: 1

      " I found every bug that the game shipped with"

      No you didn't. The fact that you think you did is frigging hilarious!

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    6. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      No you didn't. The fact that you think you did is frigging hilarious!

      My boss was the lead tester for that video game. He confirmed that I found every open bug that the video game shipped with. He was very impressed that I found them all.

    7. Re:Been there, done that... by Zero__Kelvin · · Score: 1

      " He confirmed that I found every open bug that the video game shipped with. "

      "I found every bug that the game shipped with"

      Show me the word open in your original statement.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    8. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      Show me the word open in your original statement.

      Why should I entertain your nitpicking? You obviously don't believe what I wrote. Not the first time, not the second time, and probably not the third time.

    9. Re:Been there, done that... by Zero__Kelvin · · Score: 1

      "Why should I entertain your nitpicking?"

      That is rich. A supposed highly qualified software tester who thinks that identification of the omission of an element that completely changes the meaning and context is "nitpicking". Yeah. You're great at your job buddy. Off you go now ...

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    10. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      A supposed highly qualified software tester who thinks that identification of the omission of an element that completely changes the meaning and context is "nitpicking".

      If you think that being a video game tester is equivalent to being a "highly qualified software tester," you don't know shit about software testing.

      You're great at your job buddy.

      I was a video game tester for six years. I spent the last 14+ years in IT support.

    11. Re:Been there, done that... by Zero__Kelvin · · Score: 0

      "If you think that being a video game tester is equivalent to being a "highly qualified software tester,""

      Wow. You really are a complete fucking idiot :-)

      " I spent the last 14+ years in IT support."

      Never mind. That is so much better. Details are certainly not important in IT support! ROTFLMAO

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    12. Re:Been there, done that... by __aaclcg7560 · · Score: 1

      Details are certainly not important in IT support!

      Details, no. Problem solving, yes.

  16. Re:what about having real qa & not endusers / by show+me+altoids · · Score: 1

    This is what killed Anton Yelchin.

    --
    I feel sorry for people that don't drink, because when they get up in the morning, that's as good as they're gonna feel
  17. Isn't this mutation testing? by Sits · · Score: 1

    I thought this was already called mutation testing in Computer Science. At least in that you create variants of the original program with subtle changes so you can see which mutants are "killed" (aka detected) by your test cases. The more mutants you kill the better the test suite. It seems strange the paper doesn't reference that research at all...

    1. Re:Isn't this mutation testing? by Anonymous Coward · · Score: 0

      Probably because it's also just called "testing". There's nothing special about this. You throw test cases at it that you know should pass and know should fail. If things that should be detected are detected and things that should be passed through are passed through, the test passes. Then you move on to the next stage, which is called "deployment". It's basically the same as a large test case, only someone else provides the inputs.

  18. They're not bugs. by ChrisMaple · · Score: 1

    They're features.
    And by adding more features, we're getting less - if it's Microsoft.

    --
    Contribute to civilization: ari.aynrand.org/donate
  19. Article summary sucks by CrashNBrn · · Score: 2

    The research showed that the bug-finding tools they tested had a dismal aggregate detection rates -- 2%. Not only that, they often found bugs that weren’t even there, creating unnecessary work for quality assurance teams trying to clean up software before it’s released.
    ...

    The research team is planning a competition for this summer in which developers of bug-finding software receive a score based on how many vulnerabilities their tools detect in a piece of software made vulnerable by LAVA. The idea is to help the developers produce better products.

  20. Real Bugs are Hard by Anonymous Coward · · Score: 0

    It's good to use checkers to check for dumb things. but code / syntax / etc checkers can't check sophisticated mistakes.
    heck, people often can't check for sophisticated mistakes.

    on the output side, sure if you want to have some known inputs, and run em thru the code, and see if you get expected outputs, thats good too.

    but how do you simulate what happens in memory after the servers been running for 8 hours, with various buggy video drivers running bleeding-edge code?

    or heck - how many of your known input checks go deep - like taking an ENTIRE DAYS worth of data. lots of problems start with weird corruption won't show up at first, it takes times to mess with things.

    I dont want to be down on checking, but the summary makes it sounds like "we have discovered the silver bullet". as if.

    1. Re: Real Bugs are Hard by Anonymous Coward · · Score: 0

      You want to study functional programming. The Basic idea is that instead of having objects that can have many states and are thus hard to test, you have functions that work the same way every time with the same input and thus are easy to test. I don't like pure functional programming, but I like the idea and usually I try to encapsute difficult parts Into functions that are easy to test.

  21. Obviously by Anonymous Coward · · Score: 0

    The only way to stop a bad guy with a bug is with a good guy with a bug.

  22. You found "every bug" & mastered a virus? by Anonymous Coward · · Score: 0

    how embarrassing.

    I wouldnt hire you to be anywhere near a computer

    1. Re:You found "every bug" & mastered a virus? by __aaclcg7560 · · Score: 1

      I wouldnt hire you to be anywhere near a computer

      I'm currently a system admin with responsibility for 80,000 workstations in government IT. Rest assured. As a public servant, I'm here to help you.

  23. Throw an exception by Anonymous Coward · · Score: 0

    to catch an exception