Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

I wish I had written these...

I wish I had written these...

  • Comments 25

From Eric Sink, via Dana Epp:

"My Life as a Code Economist"

And Dana's original article:

"The cost of fixing bugs..."

  • Basically shipping products with bugs (known or unknown) is lame - it's tolerated only because otherwise, it would lead to cost explosion - it is already very costly to buy and use any software with even a small level of complexity.

    That does not of course mean that shipping *bug free* software is impossible - that's an huge insult of Engineering profession. (Imagine Aeroplanes, Nuclear Power plants etc. built and commissioned with bugs, even consider CPUs - for the complexity, they have far less number of bugs than any operating system.)

    Software Engineering could benefit hugely from having completely effective processes, intelligent tools and engineers who religiously follow them. Any one who ships buggy products is missing at least one of the above.
  • Yawn.
    The cost of a fix that these articles talk about directly depends on how much the code is garbage to begin with. It is never zero but it is far greater for MS than it should be. Instead of committing 100% of your resources to pushing the next big wave of unreliable crap (aka .NET) concentrate on techniques to write robust code. This will decrease your bug fix times and costs and change the balance in the equation. Note that "robust" is more than "secure". The security scrub you went through is just the tip of the iceberg.
  • Economics? I've had enough previous employers where the cost of fixing a bug was blamed on the person who reported the bug. After seeing a posting by one of your colleagues who was penalized for helping to improve bug reporting, plus a few comments on MiniMsft's site, it sort of looks like Microsoft is par for that course.

    There are more than two groups of software engineers. Some have different opinions than others about what kind of bug should be considered a show-stopper. Some have different opinions than others about whether warranty service should be provided.
  • * full disclosure: I am the moderator of webappsec@securityfocus.com

    I find this discussion amusing as it is more than 10 years old, and still hasn't really been put to bed yet.

    "Responsible disclosure" requires "responsible software vendors".

    When vendors do not fix their software, we get people pushing out exploits prior to fixes being available - a lose-lose situation.

    When vendors exploit a disclosure policy to put off doing the right thing, we all lose. Back in the day, SGI used to be the boogyman. CERT would sit on vulnerabilities literally for years until the vendor notified CERT that they had a fix and had spread it around their customers. SGI exploited CERT's policy. full-disclosure@... was born out of that *failed* "responsible disclosure" policy.

    By common assent, bugtraq mostly adheres to RFP's disclosure policy to *encourage* vendors to fix and test in a reasonable time frame.

    However, I know how hard moderating a high volume list can be as I look after webappsec. I do not let 0days out on my list, but I allow discussion which may lead to new attack types. This is responsible as if the security professionals are thinking about it, you can bet your bottom dollar that attackers are thinking about it, or already have.

    I strongly advocate development of preventative measures along with pure attack paths. Without preventative measures, we will just become more and more vulnerable as time goes on. That's why I re-wrote the OWASP Guide 2.0 to be a positive book, and minimized the total number of negative "thou shalt not" entries.

    However, getting back to the original topic. In 2002, I presented a talk to linux.conf.au stating unequivocally that if you use dangerous languages like C or C++, you are responsible for not releasing code which has buffer overflows and other preventable flaws. Most user land utilities and applications could be recoded with some effort in C#, which is for the most part unaffected by buffer overflows.

    Dana has a point, but it's a very naive point of view. We need to have *some* pressure on vendors as they have shown to be less than forthcoming in the past (SGI, Cisco), otherwise we all lose. But we also need to allow security researchers to freely communicate their findings and research so that we can develop techniques to prevent security flaws.

    Andrew
  • till_pero, clearly you've never worked as a professional software developer (or at least not on any project of reasonable complexity).

    There are NO projects that ship without bugs. None. Even mission critical ones like the projects that run airplanes, nuclear power plants and space ships. Those applications have a very low tolerance for bugs, and have a massive amount of overhead associated with ensuring that the project have as few defects as possible, but they still ship with bugs.
  • The problem is that most bugs can't be foreseen. Who knows how a system is going to act when it's living in the wild, when it's performing with input that it wasn't tested against, when the components are grinding against each other in ways they never have before. Until we come up with a way to test against all possible input cases imaginable (ha!), or adopt formal code proofs as the norm (double ha!), software with bugs will ship.

    "Program testing can be used to show the presence of bugs, but never to show their absence." – Dijkstr
  • "...how much the code is garbage".
    No, it is how complex the code is already.

    Nobody with a sane mind *WANTS* to ship a product with bugs. The visibility is more in systems that exposes an API to an external team or a component.
  • People who compare engineering to software engineering and claim that since bridges don't fall down on a regular basis software should be flawless bother me.

    Tell you what, when you're told to design a car that one month later has to be able to go under water, then 6 months later, right before it's due to ship, also has to be able to go into outer space, then we'll talk.

    Engineering has a set number of variables whereas software has a (practically) unlimited number of code paths.

    Given a limited amount of resources one has to determine where efforts should be directed to.
  • Larry - makes me wonder if you read my post at all. Ok, let's get this straight - it's this attitude of MS that has caused it to ship products with *nasty* bugs that explode and cause you *loss*.

    I call it a bug when a *normal* use of the product causes loss of _some_ kind for which there is no work around.
    (Mind you Windows has plenty of such bugs)

    Going by your negligent statement, we must have seen loads of air craft crashes every day. Aircraft software does NOT have bugs that occur with normal use of the aircraft and heck may be even abnormal one. PERIOD. Mission critical s/w that ships with bugs either ships with enough prevention mechanism to avoid the circumstances causing the bugs - meaning it no longer is a bug but reduced functionality which is acceptable.

    I don't recall nuclear power plant explosions caused by bugs - it performs exactly per specification.
  • Those applications have a very low tolerance for bugs, and have a massive amount of overhead associated with ensuring that the project have as few defects as possible, but they still ship with bugs.
    ---

    In engineering there is always an tolerance it's either very low or very high or somewhere in between. We are discussing of bugs - which are caused by non/mal-function of the software which in turn is caused by Higher tolerance.

    Saying low tolerance is still tolerance and is comparable to high tolerance is funny. Latter causes you loss and classifies as 'does not work per specification' == BUG, but the former, despite of being a little off than specification, doesn't cause you any loss - it's acceptable.

    Now give me an example - what bug(s) a mission critical s/w shipped with and if it did why was it call 'mission critical' at all. I tell you no real mission critical s/w did - all of them performed 'well within specification' under all practical circumstances. That is NO bug at all.

    Makes me wonder however, if Boeing sells Aeroplans with the kind of NO WARRANTY OK ANY KIND clauses that MS ships their OSes with!
  • > ill_pero, clearly you've never
    > worked as a professional software
    > developer (or at least not on any
    > project of reasonable complexity).

    So you're a "professional software engineer"? Does that mean you've taken an exam provided by the state and are legally liable for any damages caused by errors in your code?


    > There are NO projects that ship
    > without bugs. None. Even mission
    > critical ones like the projects
    > that run airplanes, nuclear power
    > plants and space ships.

    Yes, but if an airplane or nuclear plant somehow has an error that causes millions of dollars in damages, the company has to pay. So they are very careful to avoid such things.

    Microsoft, on the other hand, can cause millions of dollars of lost time and money (see the spyware problem and virus problem) and for reasons I don't understand no one ever sues.

    It's not as if MS doesn't bring in enough profits to fix most of their critical bugs if then wanted to.

  • Larry,
    there's a difference between:
    - shipping products with bugs.
    and
    - shipping products with *known* bugs.

    It is possible to ship even large systems without known bugs. Im not talking about the kind of bugs you get due to a defective (or even non-existant) QA, but the kind of bugs that slip by even extensive (but provably not extensive enough) QA.

    There are many reasons products ship with known bugs, but usually it boils down to engineers and developers being overruled by the ones wanting to make a quick buck. But whatever the reason, it's always a deviation from good business ethics - at best.
  • Yes, the POC should have been sent to Microsoft privately before (shall we say, MONTHS before) being released into the wild.

    My question, though, is this...

    How much effort does Microsoft make to investigate whether known bugs are more serious than they at first appear?

    Clearly, not enough.

    If someone points out that there's a crack in the dam, then calls the person who built the dam and says "look at the crack, it's leaking water", whose responsibility is it to check whether that crack is a minor inconvenience (leaking water) or a sign of major structural damage?

    The person who noticed the crack, or the person who built the dam?

    It AMAZES me that this person was able to discover a working exploit, even without access to the code.

    Microsoft should have been able to assess the risk of a possible exploit much more easily. Not only does Microsoft have access to the code, but they don't even have to make the exploit work... they just have to think "hey look, there's a potential buffer overrun here."

    Easy fix.

    Food for thought:
    http://www.fordham.edu/halsall/ancient/hamcode.html
    "... if a man builds a house badly, and it falls and kills the owner, the builder is to be slain..."

    St. Francis Dam - worst civil engineering disaster in US history
    http://en.wikipedia.org/wiki/St._Francis_Dam
    "... On the morning of March 12, Harnischfeger discovered a new leak and worried that it was undermining the dam. Mulholland, his son Perry, and assistant Harvey van Norman investigated. Perry thought the leak looked serious, but Mulholland felt it to be typical of concrete dams, and declared the leaks safe.

    ...

    The dam finally crumbled at 11:57 p.m. on March 12, 1928, scarcely 12 hours after Mulholland had inspected it.
    "
  • Maurits, that's a good point. Personally, I classify this in the same category as off-by-one overruns and heap overruns.

    Two years ago, if you'd asked a security professional, they would have told you that a one byte overrun of the stack wasn't exploitable. Then the hackers showed how it was exploitable. Similarly with heap overruns.

    Our knowledge of what is exploitable and what is not exploitable constantly changes over time. This is why Microsoft requires that developers take ANNUAL security training - because the exploit landscape constantly changes.

    From what little I've seen about this particular problem, it appears that something like that happened here - a condition that was previously thought to be unexploitable was shown to be exploitable.
  • Monday, November 28, 2005 11:10 AM by vince

    > and for reasons I don't understand no one
    > ever sues.

    Legal proof is far far harder than engineering proof. Even when you can accomplish legal proof, it's rare for awards to even cover the expenses. The outcome shown in "A Civil Action" is more common than "Erin Brockovich", but more common than both is for the case to just be abandoned because victims can't afford to produce legal proof.

    Monday, November 28, 2005 5:52 PM by Maurits

    > http://www.fordham.edu/halsall/ancient/hamcode.html
    > "... if a man builds a house badly, and it
    > falls and kills the owner, the builder is to
    > be slain..."

    Yeah, but if the builder can afford better lawyers, and if the builder isn't stupid enough to do something like telling the truth in court, then how are you going to prove it...
Page 1 of 2 (25 items) 12