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

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

    Hm, it's a bit longer then 2 years tho, it's 6:

    The timeline surrounding new bugclasses (or partial new bugclasses) is interesting tho. Usually they are known for a very long time to a select group of people and it's not untill someone raises a big stink about it that other people know or care about it.

    A good example is formatstring bugs, they've been documented since adleast 1988 (The C programming language 2nd edition). Very few people knew about it untill 2000 when all hell broke lose and everything turned out to be vulnerable to it.

    Whenever the public at large is introduced to a new bugclass it's always interesting to go look if you can find earlier references to it. You usually can! it's just that no one seemed to care about it back then.

    The thing is most bugs have the potential to be security bugs when placed in the right context. It's just expensive to think about a bug (that's not yet seen as a security bug) for a while and try to come up with a security sensitive context for it.

    I agree with larry that constant dev. education regarding security is needed. He's absolutely right, the exploit landscape is constantly changing and it's changing more rapidly then it did a decade ago !
  • Sometimes I wonder if people just need a target to rant against! Seriously ... relax, people. Speaking from 20 years in IT, MS is by no means the worst bug shipper/admit-er/fix-er. All other vendor provide shoddy support from time to time ... in my opinion the cumulative worst is another major sw/hw/services vendor.
  • till_pero:

    Building software is not easy. It is a complex task. There will always be bugs. You say it is lame to ship with bugs (known and unknown). First, if it is a unknown bug, you didnt know it existed when you shipped the product, so there is nothing that could have been done about this in hindsight. As regards known bugs - again, it depends on the severity/priority of the bug. If you take the position that you will never ship software with a known bug, then very few projects will get to customers. The reason? Fixing bugs sometimes introduces more bugs. Also, QA tests are sometimes not complete, so they dont catch all the bugs in software. Also, you get to the point of diminishing returns after some point. Do you want to hold up a product ship just because the "OK" button in a dialog box is off by one pixel?

    Let us talk about mission critical software. I dont have the link offhand, but if you go to slashdot, you can search for one of the posting which listed 10 top bugs of all time. There have been incidents where people were injected with the wrong dose by a medial device because of a bug in the software. NASA lost the Mars Observer, because one contractor was working in metric units while the other was working with inches. It was a bug in the process!

    Having said that - is there room for improvement? Absolutely - and we are doing it everyday. Sometimes we are successful and sometimes not, but I can say with confidence atleast about my team that we are focused on delivery quality code.
  • I wanted to add to my post on this subject. Another bug that hit a mission critical piece of software was with the first Mars Rover. They had a bug in the software that did the scheduling, and it caused the Rover to malfunction. It was a very subtle bug, I grant you that, and they could fix it remotely as well. Anyway, the reason I brought this up was to give another example of a bug that hit a critical piece of software.

    I would also like to add that sometimes mistakes do get made. People make the wrong judgement about a bug and dont realize the impact it might have down the road. So, yes, sometimes software does get shipped with "known" bugs. However cases like this should not be very many. No project manager, whether at MS or elsewhere wants to ship software that will have bugs in mainline customer scenarios. And where this happened, managers are made accountable. Now, again, as I said previously, there are definitely instances where this process does not work perfectly. However there shouldnt be too many of these instances.

    Bottom line is - there are other alternatives now. We know that if we dont do a good job and ship shitty bug ridden software, then customers will vote with their dollars and go elsewhere.
  • Interesting... we keep coming back to market impact as the driver for bug fixes. Many businesses do not have this vaunted ability to "vote with their dollars". Consider that there is a cost attached to system migration, and that such a cost might be so high for technically-reliant businesses that they will surely go under if the migration is undertaken. A business in such a position will stick with the buggy system they have and pray.

    I see these "economics of software design" themes fairly frequently in the MS blogs, and why not? That is the the model that MS approaches business with. Eric Lippert's "How many Microsoft employees does it take to change a lightbulb?" is a somewhat more humourous article in a similar vein. Unfortunately, I see a few people missing from Eric's list, like the number of marketing people involved in promoting said new feature, or the number of people making said feature accessible for his blind Catalan-speaking Spaniard, who happens to be a deaf quadriplegic as well.

    All this brings up a point that occurred to me: what if all that effort devoted to market-broadening localization, accessibility, and marketing were put into software development instead? As someone once mentioned, "Fewer clients, less money". Not that the disabled or those who don't speak English don't deserve great software, it's just that they (and everyone else) don't deserve to have to wonder if their computer will be working tomorrow.

    Of course, if Microsoft did anything that increased quality at any cost to their customer base or advertising juggernaut (and hence to their bottom line), some other voracious being would just step in and start it all over again. These tradeoffs are made not to stay in business, but to remain on the top.
  • Andrew,

    As some of my comments on my blog point out in the original article, I agree that we need to place pressure on the vendors from time to time. My point though is that pressure needs to be applied through a responsible workflow. If security researchers really wish to protect the safety and security of their clients while elevating their own credibility in the industry, they must follow responsible disclosure practices.

    Researchers have every right to be able to disclose their findings. The balance is doing so while respecting the well-being of the rest of the Internet. This wasn't the case. They didn't even make an effort to notify MIcrosoft beforehand.

    And I am not absolving Microsoft from responsibility here. They have a TERRIBLE track record when it comes to responding to some threats (see EEyes Upcoming Advisories on just a few examples of vulnerabilities going on over 200 days now). But its hard to work on those when they have to respond to new attack patterns that are in the wild.

    Further to this, Microsoft showed their human frailty in their security response practices with this incident. During triage of the original bug a threat model would have been performed and it is apparent this attack vector wasn't even considered. And it should have been. But now its a moot point. Now they are in defensive response mode in an effort to protect all their clients.

    How does the irresponsible disclosure benefit us as the user? It doesn't. It actually put us all at MORE risk. And that's not acceptable.

    Naive? Perhaps. But that's because I believe in the disclosure process. It requires both sides to work. When either side collapses, the whole thing is shot. This incident is proof of that.
  • PingBack from

  • PingBack from

  • PingBack from

  • PingBack from

Page 2 of 2 (25 items) 12