Forgot your password?
typodupeerror
Microsoft Bug Programming IT Technology

Why Can't Microsoft Just Patch Everything? 640

Posted by Zonk
from the they-need-more-cookies dept.
paneraboy writes "If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities? Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit. Currently, more than two dozen Windows XP issues remain unpatched. Ou thinks Microsoft ought to fix them all." From the article: "Almost 4 years after the launch of Trustworthy Computing, I found myself wondering why am I staying up till 4:00 AM to deliver an emergency set of instructions (Home and Enterprise) to my readers because Microsoft felt it unnecessary to patch a flaw six months ago that was originally low risk but mutated in to something extremely dangerous."
This discussion has been archived. No new comments can be posted.

Why Can't Microsoft Just Patch Everything?

Comments Filter:
  • Good ole' 2002 (Score:3, Interesting)

    by rd4tech (711615) * on Thursday December 01, 2005 @10:47AM (#14157144)
    Here's one from the article flagged: "Less critical" from 2002: SA7127 [secunia.com] Check out the first paragraph of this 'less critical' item's description.

    By the way, when I read a statement like this one:
    If smaller software companies can patch all of their bugs serious or minor, why can't Microsoft just patch all of their vulnerabilities with their massive army of programmers and massive budget?
    I start thinking there ought to be some kind of credibility (karma) system for anyone giving public opinions. You know, give the article '-1', give the guy 'Terrible Karma'. Make all his subsequent articles dissapear for you, or even better, replace the article with a 'joke of the day', you know, to dilute the real news a bit.
    • Re:Good ole' 2002 (Score:2, Insightful)

      by Doc Ruby (173196)
      You mean like when someone says "if smaller software companies can patch all of their bugs" means "if all smaller software companies can patch all of their bugs"? Thanks for the permission to flag all of your future posts as "joke".
      • no, I didn't mean that ;)
      • by Numen (244707) on Thursday December 01, 2005 @11:44AM (#14157810)
        The initial post is a strawman argument...

        If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks ...which predicate the argument on the notion that small software companies patch all their bugs.

        So if I go looking for bugs in say the Opera browser I wont find any, because small companies patch all their bugs?

        Nobody patches all their bugs; not small companies, and not large companies. The argument is a piece of sophistry that simply sets up another round of MS bashing. A fun sport, but it shouldn't be mistaken as anything exccept sport.
        • by Doc Ruby (173196) on Thursday December 01, 2005 @01:10PM (#14158747) Homepage Journal
          Actually, some small companies do patch all their bugs. Especially when we're talking about reality, the facts that matter: reported bugs, known bugs, security bugs. While Microsoft, which could patch all those bugs with their vast resources and experience, does not.

          Some more points about your criticism: strawman arguments [princeton.edu] aren't what you accuse the original post of being. They are weak or sham arguments created by an opponent to easily refute, not arguments made by the original party. And your Opera example is predicated on exactly the strawman I pointed out in the reponse to the original post: you read "if smaller software companies" as "if all smaller software companies", and then argues that one smaller company doesn't patch all of their bugs. When in fact the implicit qualifier in "if smaller software companies" is "if some (or any) smaller software companies". So their predicate is valid if even a single smaller software company patches all its bugs. And, as I mentioned, the bugs that matter in this argument are those that are reported, known, and security. If you insist on "all bugs" being literally all-inclusive, you're arguing for that release to be the final one, without even new features - sometimes known to some users as fixing bugs of omitted features.

          So, as usually seen in posts by people who call factual, logical criticism "bashing" (of MS or any other party), you at last accuse the fair criticism of being "sophistry" and "sport". True to form, you project the serious flaws in your own strawman and absurdly reductionist argument onto your targets. It might be sport for you, but it's unsporting conduct.
    • Re:Good ole' 2002 (Score:3, Interesting)

      by /ASCII (86998)
      It _is_ a less critical bug. All modern linux systems have the same 'bug' by design, and not only for 16-bit applications. The consensus is that this is not worth fixing. (To execute an arbitrary file, even one on a fs mounted noexec, simply use ldlinux.so to launch it)
      • Re:Good ole' 2002 (Score:5, Informative)

        by Tony Hoyle (11698) <tmh@nodomain.org> on Thursday December 01, 2005 @11:30AM (#14157655) Homepage
        That problem was fixed, um... 4 years ago?

        $ /lib/ld-linux.so.2 ./test ./test: error while loading shared libraries: ./test: failed to map segment from shared object: Operation not permitted
  • by MSFanBoi2 (930319) on Thursday December 01, 2005 @10:47AM (#14157146)
    Seems like some members of the press don't understand coding. You can't just go and patch everything. Regression testing? Making sure all the changes work as needed without impacting other subsystems.

    Do you really think if Microsoft COULD do it, they wouldn't.
    • by redfirebmd (815070) on Thursday December 01, 2005 @10:54AM (#14157226)
      Seems like some members of the press don't understand coding. You can't just go and patch everything. Regression testing? Making sure all the changes work as needed without impacting other subsystems.

      Do you really think if Microsoft COULD do it, they wouldn't.

      Whereas I agree with you that it isn't as easy as some people think, if any company in the world has the resources to do it, its Microsoft. I see NO reason why a company with this many people and this much money can't get good patches out the door soon after vulnerabilities are found. The only exlplanation is poor organization and bureaucracy.

      • by liquidpele (663430) on Thursday December 01, 2005 @11:38AM (#14157752) Journal
        No, the explaination is that they do the minimum they have to do in order to keep people just happy enough to stick with their products. This is true in a lot of markets. Keep your customer happy enough so you don't loose them, but don't waste money trying to make the product perfect.
        • "Quality" (Score:5, Insightful)

          by RealProgrammer (723725) on Thursday December 01, 2005 @12:13PM (#14158118) Homepage Journal
          the minimum they have to do in order to keep people just happy enough to stick with their products.

          There was a business mantra in the '90s, and still out there today, that defines "quality" as whatever it takes to please the customer. Consultants hauled in buckets of money generating cliches out of that. Companies may be driven by customer satisfaction, which is fine as far as it goes, but it doesn't mean their products are any good.

          The flaw in the cliched definition is that often the customer doesn't know what they're getting or have any basis to judge how good the product is.

          Microsoft, being driven by market share, is a step removed even from that level of quality. They only want their customers to be happier with their products than with the competition (which is often another of their products or an earlier version of the same one).

          Making things properly is not in their range of capability.

      • by rocjoe71 (545053) on Thursday December 01, 2005 @11:39AM (#14157763) Homepage
        I see NO reason why a company with this many people and this much money can't get good patches out the door soon after vulnerabilities are found.

        I agree with you that it's pissheaded of any software company to ignore fixing their security holes, I would suggest that that their "reason" would have something to do with the fact that a new version of Windows and IE are on their way, that don't have the same holes, and the cost/effort to fix those existing problems would be too costly to the newer versions (going from the IE Blog, alot of the IE 6 team has something to do with IE 7, and the WinXP team is involved in WinVista).

        That being said, perhaps the problem here is that it costs less for Microsoft to ignore security holes than fix them. That would mean the solution is to forget adding to the "Microsoft so bad" arguments and start pressuring lawmakers to punish companies that are negligent and exposing consumers to harm.

        Once the cost of inaction is greater than the cost of action, we'll start seeing a difference.

        • I would suggest that that their "reason" would have something to do with the fact that a new version of Windows and IE are on their way, that don't have the same holes, and the cost/effort to fix those existing problems would be too costly to the newer versions (going from the IE Blog, alot of the IE 6 team has something to do with IE 7, and the WinXP team is involved in WinVista).

          While that may be true now, what was the IE6 team up to for almost four years while IE 6 was left out to dry like a bastard step
      • I think you have hit on a, if not THE, reason MS has problems providing timely patches. It's bureaucracy. Take a look at any large company/institution (i.e. automotive companies, government, etc.). I know from personal experience working for both government and a very large global company that it takes forever to get anything done. This is due to the simple fact that the decision process takes forever because of the number of people that have to sign off. You do not have this problem with smaller companies
    • by Shakrai (717556) on Thursday December 01, 2005 @10:56AM (#14157260) Journal

      Do you really think if Microsoft COULD do it, they wouldn't.

      Just because they CAN do something doesn't mean that they WILL. Anybody care to remember what it was way back in the day with Microsoft software? Anybody remember how they ignored holes that were exploited far worse then this one until the public outrage overwhelmed their PR spin?

      They don't look on security as anything other then a marketing ploy.

    • by cnelzie (451984) on Thursday December 01, 2005 @10:58AM (#14157288) Homepage
      Of course, if the base design philosophy is flawed to begin with, even if they could "patch everything" the would likely be better off rewriting from the ground up.

          Many components of Windows and MS Software on Windows utilized Remote Procedure Calls, even if the applications are on the same exact system. This is inherently flawed, as shown in many past MS Windows exploits. Just look at the MS-SQL expoits as perfect examples.

          If designed with security, instead of "ease of coding" was the design from the start, RPC wouldn't be used for communication between processes on the exact same piece of hardware. This is how it is done with MySQL and Apache on Linux and why RPC exploits won't work if those services are running on the exact same hardware.

          The list of flawed design decisions that went into Windows at the very beginning continue to haunt the Windows Operating System to this day. No, I am not some blind unqualified moron making these statements, I manage Windows desktops for a living, used to work full time with Windows Servers and one of my hobbies has been looking into OS architecture design and how it relates to system security.
      • Mod parent up! (Score:5, Insightful)

        by khasim (1285) <brandioch.conner@gmail.com> on Thursday December 01, 2005 @11:20AM (#14157545)
        There are two types of "patching".

        1) Patches to fix code flaws in an otherwise sound security model.

        2) Band-aids for a flawed security model (anti-virus updates are in this category).

        Microsoft focused on "user friendly" and "easy of use" for so long to the detriment of security. And security cannot be retro-fitted to a system.

        When they merged IE with the OS, just to be able to beat Netscape, they opened the OS to a whole new category of exploits.

        And then ActiveX made web app programming so much easier ... and opened a whole other category of exploits FOR THE OS.
        • Re:Mod parent up! (Score:5, Informative)

          by cnelzie (451984) on Thursday December 01, 2005 @11:26AM (#14157597) Homepage
          Well, ActiveX was really initially designed to not only "kill" Java (which didn't work), but also to attempt to lock everyone into using Windows running PCs for using the Internet. (Thank whatever belief system you have that didn't work.)

              By tying ActiveX so tightly into the OS, they not only succeeded in making ActiveX an almost required component of any Windows Installation, they also knee-capped themselves in regards to handling security. Unless it is seperated from OS, ActiveX will always be a threat to the security of a Windows PC.
          • Re:Mod parent up! (Score:3, Insightful)

            by mpe (36238)
            By tying ActiveX so tightly into the OS, they not only succeeded in making ActiveX an almost required component of any Windows Installation, they also knee-capped themselves in regards to handling security.

            It's not just ActiveX. One of the examples linked to in the article involves a corrupted font file being able to bring the OS down.
            At least a part of the problem is Microsoft deliberatly writing "sphagetti code" in order to make applications be a part of the OS.

            Unless it is seperated from OS, ActiveX
        • Re:Mod parent up! (Score:5, Informative)

          by dioscaido (541037) on Thursday December 01, 2005 @12:34PM (#14158335)
          IE does not run in the kernel. IE exploits have nothing to do with any 'integration into the OS'. IE exploits are the same as any other user level running process. If you could run Active-X in Firefox, or found the same javascript exploite, or other exploits, you would get the exact same range of system impact as with IE. The issue is that for 'ease of use' MS chose to have everyone run as root, which is probably one of the most boneheaded decisions ever. If you run as Limited user IE exploits are contained to your user directory, the same as they would be as non-root in linux. Vista will finally push everyone to the limited user realm, and IE 7 on Vista is absolutely anal when it comes to having any kind of priviledge on the system. We'll see how well it all works out.
      • by mmjb (866586) on Thursday December 01, 2005 @11:30AM (#14157653)
        Of course, if the base design philosophy is flawed to begin with, even if they could "patch everything" the would likely be better off rewriting from the ground up.
        Outstanding idea!

        1. Base it on tried and tested code. Maybe supply the source code for the world's programming talent to see if there is anything wrong with it. Also encourage help with new projects.

        2. Give it a snappy name - words ending in an "x" always sound cool.

        3. Oh - and it would need a logo - maybe from the animal kingdom?

        4. ...

        5. Profit! (Oh - wait...)
    • Exactly. I don't program, I've just read Slashdot for the last few years or so (UID war?) but even I know that software is so interrelated, especially something with a codebase as large as Windows, that if you change one area, there will be effects somewhere else. You cannot change many things at the same time because you will never be able to figure out which did what. You have to do things serially. That's why you cannot fix Windows all at once.
    • I'm sure it's not helped any that they moved most the IE engineers that understood it's design to other projects or that IE itself is obviously in horrible need of a major overhaul. Making the clever decision to tie it tightly into other programs and the OS was another good idea that has benefited IE's security and ease of repair and testing.

      May I suggest they refactor IE a bit? Maybe starting by switching to a more modern and secure engine like Gecko or KHTML? IE doesn't earn them anything directly and the
    • by js3 (319268) on Thursday December 01, 2005 @11:50AM (#14157908)
      preach on brother!

      that OP question is a dumb as "why can't the US kill all the terrorists? with their large army and all their technology?". We'll put in the same bin as "why can't you marry britney spears" and "why can't you quit your job and become a scuba diver"
    • That was my first impression when I read the original post, although you put it in much nicer terms than I was planning to. It sounds like plain ignorance to me. "Patch everything"? Even someone with a year or two IT experience would know that simply isn't possible. I think media covering IT should be required to know a good amount about the industry they are covering.
    • YES!

      If it doesn't put money in Bill's pocket, it isn't done at Microsoft.

      Look at their new "security" software. It is going to be CHARGED for. They created the crap that produced the need, and now they're going to charge for fixing it.

      Assholes.
    • by jd (1658)
      It is certainly possible to fix all of the bugs in any piece of software, but NOT by code audits and testing. If you rely on testing then if you have N different modules in the code, you have !N different ways those modules could interact. N doesn't have to be big to make this an impossible task.

      Instead, you take the software and reverse-engineer a mathematical description of it. Once you have a mathematical model, you can use theorum provers to determine what parts of the code are mathematically illogical/

  • Well ... (Score:3, Funny)

    by SpooForBrains (771537) on Thursday December 01, 2005 @10:48AM (#14157151)
    To paraphrase a certain mercenary, where's the percentage in that?
  • by Speare (84249) on Thursday December 01, 2005 @10:48AM (#14157155) Homepage Journal
    You can only patch a leaking boat so much, even if you drydock the vessel for a few months. When it's only held together by the barnacles and the masthead, it's going to sink whether you bail it out or not. At some point, you're going to have to re-think the design of that hull, and start from scratch.
    • by Reziac (43301) * on Thursday December 01, 2005 @11:03AM (#14157353) Homepage Journal
      And unfortuntely, over time your new hull will grow its own barnacles and weed, and you'll find that some of the planks used weren't as sound or warp-free as they appeared, and maybe the craftsmen who designed it weren't quite as expert as they thought, either. So sooner or later you'll have to tar that hull's leaks too. And the more rough seas and heavy cargo the boat experiences, the more often you'll have to tar it.

      Not to mention that a new hull design, or switching from sail to diesel, might require that you retrain all your sailors too!

      • by dexter riley (556126) on Thursday December 01, 2005 @11:25AM (#14157589)
        Attention all hands! Abandon metaphor! ABANDON METAPHOR!!!

        Though I must admit, it gives new meaning to "software piracy". Ahrrrrrrrr.
        • Reminds me of a Daily Show clip from the democratic convention:

          Stewart: "[Bill] Clinton also became speaker number 683 to mention Kerry's naval service:"

          Clinton: "Since we're all in the same boat, we should choose a captain of our ship who is a brave, good man, who knows how to steer a vessel through troubled waters, to the calm seas and clear skies of our more perfect union."

          Stewart: "Saying 'ahoy' to prosperity. Ending our economic scurvy... with the oranges of fiscal responsibility. Kerry's the right man
  • by malcomvetter (851474) on Thursday December 01, 2005 @10:48AM (#14157157)


    I think MS has come a long way from where they were, but I agree. To the people who claim it can't be done: OpenBSD [openbsd.org] does it!

    • by Anonymous Coward
      Yes, now let's compare the functionality of a base install of openbsd to a base install of windows... eureka I understand now!

      You can go on to claim 'well then just install secured packages as well', but it turns out third party apps never run as well as integrated apps. And microsoft is aiming at the people who want a working system out of the box, not a system that's basically a clean slate that you need to draw up yourself.
  • by nuggz (69912) on Thursday December 01, 2005 @10:49AM (#14157170) Homepage
    Why should they?

    People will still buy thier product, people accept that it sucks.
    Unless they see a good ROI on patching or developing good code they won't.

    Quite honestly if it isn't a worthwhile use of their resources they shouldn't patch code.

    When there is serious competition and code quality becomes a competative advantage they'll fix it.
    • by pubjames (468013) on Thursday December 01, 2005 @11:20AM (#14157544)
      People will still buy thier product, people accept that it sucks.

      This is something that winds me up terribly about Microsoft, or rather, the people who use Microsoft software. For example, a friend has had absolutely terrible problems with his Windows XP laptop, tearing his hair out stuff with viruses and worms and other issues. He was going to buy a laptop for his wife and asked me for my advice. I said, buy an Apple laptop and you won't have all these problems. So what did he get? Another windows machine. Why? WHY??? Because everyone uses Windows, and he was afraid of something different. And this isn't the only example.

      I got my old mum and dad a Mac Mini - they love it, and their friends coo over the slide show software and ask me how to buy one. I explain it's an Apple computer, it's cheap and compatible and will have all the software they need already installed. Then I find out later they've brought a Windows machine, because their son uses one and they were afraid that if they got an Apple they wouldn't be able to email him.

      Microsoft survives because of the fear most people have of something different. Drives me nuts. My only recompense is saying to these people "You asked my advice and I said buy a Mac then you wouldn't have these issues. So sorry I can't help you. " when they phone me to solve their stupid problems...

      Rant over.
      • Compared against other hardware of similar performance, it's not cheap. it's not compatible with most popular software available (since most of it is for Windows), and if you think needs are going to remain consistant, you're lying to yourself. A Mac, out of the box, is not a cure-all. A starting point, sure, but don't make it sound like it's a 'one-shoe-fits-all' appliance that they will never need to modify or add to. A lot of people can't move to Macs, because they use software which simply isn't ava
  • not a priority (Score:5, Insightful)

    by iggymanz (596061) on Thursday December 01, 2005 @10:49AM (#14157177)
    Microsoft is growing and profitable having their developers do other things, until such time as they are held hugely financially liable for their bloated buggy crap they won't make that their prime focus
  • by AEton (654737) on Thursday December 01, 2005 @10:50AM (#14157180)
    Issuing patches is dangerous.

    Every time Microsoft patches its software, hackers use their patches to discover security holes and to issue exploits!

    But when they don't patch their software, no bad guys notice these vulnerabilities. In fact, no virus or worm has *ever* exploited a vulnerability before a critical update was released!

    Duh.
    • Re:Doesn't he know? (Score:2, Informative)

      by GauteL (29207)
      "In fact, no virus or worm has *ever* exploited a vulnerability before a critical update was released!"

      Do you have any sources to back up that statement? It sounds highly dubious as there was just a trojan that exploited an unpatch vulnerability reported earlier today [slashdot.org] on Slashdot. I find it very hard to believe that there have been no worms or viruses, *ever* to exploit an unfixed vulnerability.
  • by xtracto (837672) on Thursday December 01, 2005 @10:50AM (#14157183) Journal
    Why can't the Mozilla Software Foundation allt the 6300 [mozilla.org]
    Firefox Bugs? instead, they have to release a "new" version... just freeze the freaking lreleases and patch your bugs!

    No, OSS is not free of bugs
    • You are comparing Microsoft's cargo ship full of oranges to Firefoxes handful of apples and you think this is relevant?
    • by MouseR (3264) on Thursday December 01, 2005 @11:29AM (#14157649) Homepage
      No, OSS is not free of bugs

      But their bugs are free.
    • by abscondment (672321) on Thursday December 01, 2005 @12:01PM (#14158008) Homepage

      Note the vast majority of "bugs" in bugzilla that are labeled "enh" --> those ones are enhancements that users would like to see.

      Instead of counting against Mozilla, the fact that they allow so much user input is a great OSS feature.

      No one said OSS was free of bugs. Since end users are allowed to submit bugs, the only ones that should be counted are those that are confirmed.

      Try the following list: bugs that are in Firefox, not marked "enh", and have an action priority (P1-P5) [mozilla.org]. (note: copy/paste link since bugzilla refuses connectiosn referred by /.)

      Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.

      The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.

  • by gasmonso (929871) on Thursday December 01, 2005 @10:51AM (#14157186) Homepage

    The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.

    gasmonso http://religiousfreaks.com/ [religiousfreaks.com]
    • by Shakrai (717556) on Thursday December 01, 2005 @11:02AM (#14157334) Journal

      The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.

      As much as I agree with you about Office and Microsoft in general I think you'd be hard pressed to find someone that can say with a straight face that Windows 98 remotely compares to the 2000/XP line. Anybody remember 95/98? I remember that I could never keep it running more then a day or two. I remember that having to kill mIRC would often take Windows down with it (WTF???). I remember running out of "system resources" long before I ran out of RAM (what good is RAM if there are artificial limits on "resources"?).

      If you want to blame Microsoft then blame them for XP not adding anything to Windows 2000 other then eye candy and phone-the-mothership code. Blame them for rolling out ME for no other reason then to exploit more revenue out of the 95/98 kernel. But don't say something stupid like Windows has been stagnant since 98.

      • I'll stick by my original statement, but will add one point. With all the resources available at M$, Windows has been rather stagnant since 98. Look at what Macintosh has done over the same period of time. XP may be more stable than 98, but that's to be expected. Innovation has been not existent.

        gasmonso http://religiousfreaks.com/ [religiousfreaks.com]
        • With all the resources available at M$, Windows has been rather stagnant since 98. Look at what Macintosh has done over the same period of time. XP may be more stable than 98, but that's to be expected.

          It's not just more stable. It's a better kernel model (you had to reboot just to change an IP in 98), it's more powerful (ever seen my taskbar at work? I often get up to 15 apps going -- fat chance on 98), etc, etc, etc.

          I really dislike Microsoft as much as the next guy but I think you are being too har

  • by dada21 (163177) * <adam.dada@gmail.com> on Thursday December 01, 2005 @10:51AM (#14157190) Homepage Journal
    If Microsoft fixed everything, then the companies that made programs that allowed users to work around the "flaws" in Windows would go to the federal prosecutors and demand that Microsoft be sued for having a monopoly on fixing their own bugs.

    All kidding aside, Microsoft has a huge amount of users, maybe more than any other product in existance (I didn't do the research). This does mean that more bugs will be found, and the reason behind not fixing certain bugs may be that the bug was addressed in a future rollup or patch already. Because Microsoft is a massive corporation with so many departments, it is possible that Microsoft BugCentral says "Fix this!" and Microsoft PatchCentral says "We fixed it in Article 931321 coming next week" and Microsoft ReleaseCentral says "We're waiting for a fix on another bug before releasing that."

    I'm not a fan of it, but it is really hard to just come out and say they're ignoring a bug, when it may be something deep set within the software (hard to remove) or it might be addressed but on hold for another reason (opened up another flaw?). If we think we as geeks found all the vulnerabilities, we're fooling ourselves. Windows is a massive program, and even Linux has ongoing flaws. When Linux has as many third party apps and interconnecting drivers as Windows does, I'll accept a complaint towards getting things fixed post haste. Until then, we just have to (thankfully) support third parties that give us options! (And paychecks)
  • Eureka! (Score:2, Funny)

    by PowerBallad (923647)
    I can hear Microsoft execs right now: "Well when you put it that way...why didn't we think of this before?"
  • by Bombula (670389) on Thursday December 01, 2005 @10:53AM (#14157221)
    From some Bond movie (Tomorrow Never Dies?):

    "What's the status of our new software?"

    "Ready for launch Mr Carver, and - as requested - it's full of bugs, so people will be forced to upgrade for years."

    "Delicious."

    /not serious... no, seriously.

  • by otisg (92803) on Thursday December 01, 2005 @10:54AM (#14157225) Homepage Journal
    Just because MSFT has an army of programmers, it doesn't mean it has an easier time patching its old code. Larger groups of people (be they developers or military groups or a bunch of friends going out drinking) almost always require more grooming and maintenance. Look up "Dunbar Number" - here [google.com] - I find it fascinating.

    A smaller, and thus possibly more agile group of programmers may actually be able to patch more holes than a mammoth like MSFT. Size can be a disadvantage (don't quote me on this ;)).
  • with its massive army of programmers and massive budget -- patch all of its vulnerabilities?

    This is impossible. With patches, new releases, and updates there will always be new bugs introduced, some exploitable, some not. No program will ever be invulnerable to malicious attacks. As long as a person made it another person can break it. Maybe micro$oft could be doing better at realeasing patches, but it will never be error free. And that goes for all software.
  • by postbigbang (761081) on Thursday December 01, 2005 @10:54AM (#14157233)
    Patches, no matter what they are, are woven into most things that Microsoft and developers do. There are numerous dependencies, and the numerous divisions, API sets, and partner dependencies make this difficult if even impossible to do on an ad hoc basis, as a generally available patch that breaks things is irresponsible.

    Yes, it happens anyway.

    Thie is the downside to having a huge, inter-dependent set of apps. Regression testing and dependency testing regimens have to be followed to ensure that small or even massive destabiliations don't happen. This also means that the easy stuff and the most urgent stuff (by their reckoning, not necessarily mine or yours) gets done first, and the tough stuff is just tough.

    It's also what makes the closed source model more difficult to deal with, as Microsoft isn't just one pool of programmers, rather thousands of coders working on largely interdependent projects. While it looks like they should be able to do this, it's a reality that it cannot. And it would be irresponsible for them to do so, given so many users, and so many inter-related apps. We just wish it could. That's why OSS methodologies have a bit of an edge in this context (and others).
    • That's why OSS methodologies have a bit of an edge in this context (and others).

      Not much of an edge when you consider that there are at least two bugs in Firefox which haven't been fixed for 5 and 6 years respectivily.

      Granted, they aren't as critical as the ones that come out of Microsoft, but I consider a couple of years to fix something more than a reasonable amount of time.

  • My guess is that if they did, it would take too long to test all of the patches to ensure that:

    -The patches worked
    -They didn't adversely affect other functions
    -The patches come out on the 2nd Tuesday of the month
  • by teh kurisu (701097) on Thursday December 01, 2005 @10:57AM (#14157265) Homepage

    The best way to find a bug is to take the code away from the original programmer and give it to a dedicated tester.

    The best way to fix a bug once it's found is to give the code back to the original programmer, and tell them to go fix. Because they know the code. And it's less likely that fixing the bug will introduce more bugs. Obviously, this limits the amount of people you can set to the task of fixing them - and in a project the size of Windows, there are a lot of them.

  • 1. It's better to release a last-minute patch, so when it breaks something, you can claim it was an urgent fix rather than a poor design choice from the start (aka: skip costly regression testing)

    2. Perception of fear: how can they get you to upgrade to Longhorn if there are no security issues with Windows XP? How can their spyware and other partners suceed if they close all of the holes? How can all those consultants fill their days if they're not applying patches to every workstation? They're doing you
    • by borawjm (747876)
      Most importantly, why wasn't the utmost care taken on anything that takes foreign input (browser parsers, etc).

      I'd take a gander and say because you just don't know what people are going to throw at it until you let them have it.

      It's more cost effective to release a piece of software and apply patches periodically than to attempt to work out all the bugs (which is almost impossible) before you release it.
  • There's no money to be made in fixing problems and issuing patches. The money is in sales. Create a new and 'better' version and charge to upgrade. New versions = profit, patches = lost revenue.
  • Part of the problem is that recovery CDs for a mass produced computers can't be patched. You end up with the quandry of restoring an insecure system, which you have to put online to update before it gets infected. If someone doesn't have a firewall or NAT, then too bad they are toast again.

    Also, if you "fix" something, it's not like it doesn't impact other things. Microsoft's Rollup 1 for SP4 Windows 2000 a few months ago broke the ability to save to floppy disks in Microsoft Office products. They fixed
  • And things at huge companies tend to take a long time to finish. I wonder where the point of diminishing returns sets in. Typically mid-sized companies tend to have the resources to perform their services as well as keep customer satisfaction at an optimum level.

    Maybe it's time for MS to break off into 3 sections? Just like where I work (huge municipal organization)...our project WILL save our city millions of dollars but what's happening right now? It's at a stand still because it's budget time. *sigh
  • If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities?

    Ok have I missread something?

    Small companies = 1 or 2 programs with each a couple of thousands lines of codes. Usually new program, so fresh and structured code.

    Microsoft = dozens of programs, with each a couple of millions lines of codes. Usually based on ancient versions returning to
  • Microsoft can't just patch everything as easily as it sounds. The reason is that certain features in the program actually cause the security problem in the first place. In order to quickly patch these problems and close the security holes, you would essentially disable the entire feature. Added to this, the problem is that these features are part of Microsoft's strategy in the market place. Exactly as with he Win98/IE integration. Sure all the inherent security flaws that produced could be fixed, but then y
  • by $RANDOMLUSER (804576) on Thursday December 01, 2005 @11:07AM (#14157400)
    Why don't we blame the real culprit? Microsoft's abiding love of data structures that look like this:
    struct foo {
    int length;
    char [] buffer;
    }

    Where the whole thing is allocated dynamically, based on what someone else told you the size was.

    • by daVinci1980 (73174) on Thursday December 01, 2005 @12:40PM (#14158392) Homepage
      Insightful? Clearly moderated by people who don't code for a living.

      Okay, first off, your code (as mentioned by the other poster) isn't legal C or C++. But let's fix it and discuss it how I'm sure you *meant*.

      So here's the correct code:

      struct foo {
              int length;
              char* buffer;
      };


      Now then, you argue that this is problematic because it's allocated dynamically, based on what someone else told me the size was.

      Actually, this struct doesn't appear in the Win32 or the MFC API anywhere (nor does anything that looks significantly like it), but more importantly, this kind of struct will *never* be a problem. Let's consider all of the cases:

      1) length is too large to allocate a buffer for. The code throws a bad_alloc exception when buffer = new char[length] is called.
      2) length is negative. new takes unsigned integers for allocation, so the value is actually very large and positive. The bad_alloc will be thrown in this case too.
      3) length is zero. I get a pointer to memory that is 0 bytes long.
      4) length is valid. We allocate a proper amount of space and away we go.

      Let's assume for a second though that someone gives me the buffer pointer *and* the length.
      1) length is the correct size (no issue).
      2) length is too small for the buffer (no issue, but I am wasting memory).
      1) length is larger than buffer actually is long. I write out of bounds, but in the heap. This will likely result in a crash, but NOT in an exploit. This struct could be anywhere in memory, but it will not overwrite the stack, which would be necessary to execute arbitrary code.

      Buffer overflows are only a problem when the buffer exists on the stack. In the heap, buffer overflows will result in a crash, or possibly undefined behavior. But on the modern PC, it would be impossible to use a buffer overflow in the heap to reliably execute arbitrary code.. Unless the coder in question was doing something really, really stupid (like executing code from an arbitrary instruction buffer in their structure, which you conveniently just overwrote). Fortunately for us, MS does not do anything of that nature.

      For reference, buffer overflows occur when someone does something like this:


      void GetAddress(char *& streetName, char* fullAddress)
      {
              char buffer[25]; // No one will ever give us input longer than this!
              sprintf(buffer, fullAddress); // Possible overflow
              streetName = new char[strlen(buffer) + 1];
              strcpy(streetName, buffer);

              0; // Improved : sprintf(buffer, "%s", fullAddress);
              0; // More Improved : snprintf(buffer, 25, "%s", fullAddress);
      }

      But the best would've been to do it like this:


      void GetAddress(char *& streetName, char* fullAddress)
      {
              int requiredBufferSize = snprintf(0, 0, "%s", fullAddress) + 1;
              streetName = new char[requiredBufferSize];
              snprintf(streetName, requiredBufferSize, "%s", fullAddress);
      }


      Or to not use C style reading at all.

      • Buffer overflows are only a problem when the buffer exists on the stack. In the heap, buffer overflows will result in a crash, or possibly undefined behavior.

        There are plenty of buffer overflows in the heap that lead to exploits:

        A quick Google search for "heap overflow vulnerability" returns 475,000 hits [google.com].

        But on the modern PC, it would be impossible to use a buffer overflow in the heap to reliably

        • The problem (in more detail) is as follows:

          Code is not executed from the heap (data segment), unless you explicitly point the instruction pointer there. This is actually pretty difficult to do. To do it in a standard program run, you would have to write self modifying code [wikipedia.org]. To force a program that otherwise *wouldn't* execute code from the heap, you would first need to corrupt the stack and adjust the return pointer to the pointer at your instruction buffer. But if you can't corrupt the stack, you're still
      • by Lagged2Death (31596) on Thursday December 01, 2005 @04:04PM (#14160627)
        Actually, this struct doesn't appear in the Win32 or the MFC API anywhere (nor does anything that looks significantly like it)...

        I beg to differ. MFC may not contain this sort of thing, but Win32 and the system API behind it absolutely, positively include lots of structs like that. Check out the serial port DCB struct, or many of the associated serial-communications related structs, for example. Check out almost any TAPI-related struct. Many other subsystems are the same, I'm sure.

        Usually, the length is actually used as a version code, not a buffer limit. OS code and user code can both check the length to see which version of the struct they're dealing with. As long as it's really used that way, it's not a problem.

        this kind of struct will *never* be a problem. Let's consider all of the cases:

        Allocating the struct isn't the main problem. The structs Win32 hands back can be downright baroque in their complexity, including variable length data objects and pointers to those objects. An application program written with the assumption that those data objects will not exceed some documented maximum length could easily wind up with a buffer overflow on the stack when interpreting, parsing, or otherwise manipulating a maliciously constructed struct.

        Let's assume for a second though that someone gives me the buffer pointer...

        Aren't you hosed right there? If the pointer points to your own stack, and you write through it, then bye-bye process. If what you write is some data chunk also provided by the same malicious someone, then you could very well be dumping exploit code right into your own stack.
  • In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.

    The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will lik

    • In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.


      Yes because as developer I love bugfixing and regression testing way more than implementing cool new features.

      Care to explain why OSS projects frequently have long lists of unpatched bugs if your point was even remotely close to accurate?
  • The article is making a very dangerous assumption here... assuming that other companies fix all their bugs. They are only fixing bugs that we know about. Who knows what they have found in-house that has remained unpatched because it was deemed too obscure.

    Another thing the author is missing is that these competitors stay in business by creating the impression that all vulnerabilities are fixed. Microsoft is vastly more publicly responsible than the smaller competitors mentioned. In the interest of c

  • Why can't they just churn out patches? Testing. You have to be sure the patch doesn't break something else. That's just as important as fixing the holes in the software. So many things are interdependent in Windows it's impossible to know what effects changes will have.

    Do you really think MS is sitting on code or ignoring security problems? If you do, you're naive. MS is a business - it doesn't pay to ignore these things.
  • Answer (Score:4, Insightful)

    by Tom (822) on Thursday December 01, 2005 @11:10AM (#14157444) Homepage Journal
    Incompetence, disinterest, different priorities, and no business reasons to do it.

    Oh, he didn't really want an answer?
  • by Theovon (109752) on Thursday December 01, 2005 @11:15AM (#14157493)
    We're used to OSS products that can be patched in a day, but we're also used to seeing those patches break things in unanticipated ways, often making things worse.

    We're also used to picking on Microsoft for having buggy software. But they have extensive and long testing procedures, without which MS software would be WAY buggier on release. Their software is massive (for some good reasons and some bad ones), so it's a huge undertaking to fully test it.

    In order to avoid, as much as possible, unanticipated consequences of a patch, Microsoft cannot simple make the fix and release it. An argument could be made that if they were to do that, they would often create more vulnerabilities than they started with, so releasing too quickly would be a BAD thing to do. Windows 95 is an example of something that was released too quickly, lacking certain kinds of testing entirely; you can see the unfortunate results when you try to connect a Win95 box direcly to the internet and wait 5 minutes.

    So, why can't Microsoft 'patch everything'? Here are the reasons:

    (1) First, you have to FIND 'everything', and Windows is just massive.
    (2) When you make a change, you have to test it extensively, which takes a LOT of time.
    (3) Some patches are one-liners. Some affect large amounts of code that makes it even harder to anticipate consequences.
    (4) Sometimes, you have to test things one at a time. This serializes your patch process in such a way that it just takes a very long time. This is very hard to avoid.

    The fact of the matter is that if Microsoft were to 'patch everything', we would have a lot more to complain about. People should stop asking for stupid things and be realistic.

    Even OSS projects can't 'patch everything' successfully. Sure, many of them are better designed from the start, so there are fewer things to patch, but when a patch needs to happen, the same amount of testing is going to have to happen, one way or another (either you release a beta and let it get tested for a while, or you just stick it in and wait for the shit to hit the fan and end up fixing the consequences the same amount of time later anyhow).

    Also, certain people forget that Microsoft did go on a 'patch everything' hunt and DID fix a huge number of bugs. They still didn't find everything.

    Oh, and if we're just talking about patching everything that's currently known, my argument still stands. Patching a bug of vulnerability is often quite difficult.
  • Currently, more than two dozen Windows XP issues remain unpatched.

    Really? Only two dozen? If the author is foolish enough to think that Windows only has two dozen bugs, it's no wonder he's foolish enough to think it should be easy to fix them.

    This post is not a slam against MS, but the article...
  • zero-day (Score:2, Funny)

    by supergiovane (606385)
    Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit.


    Maybe it should be named zero-year exploit.

  • I would love to see a poll asking how many people are really effected by those IE "holes".

    I would bet its such a small percentage that it is laughable. Remember, the security companies get money and PR by exposing as many holes in software as they can find. In all the lifespan of using windows and its various versions and IE I have NEVER encountered any site with any of the security problems that the "experts" jump up and down about.

    Yes they should be fixed, but they should also not be treating this stuff
  • Microsoft has alot of employees to feed large salaries to. The teams of developers, designers, programers, PR guys.. They're still giving support and updates to an OS that's coming on 8 years old, on top of all their new product.

    Now, I can't say for certain, but I imagine that means that every time they release a new OS, their support staff grows bigger, whether in house or contracted out (I'm not sure how MS handles it).

    This is ALOT of people folks.

    So, you're in charge of keeping MS a growing profitable company. Does it make sence to focus your time on patch after patch after patch, which does nothing but tie up your employees with aditional support and coding while in no way contributing to the effor of actually paying them? Do you focus on pushing out the new OS, forswearing support of a decades worth of previous OS's, Office, and other programs (I'm not going to venture a guess at what they're still supporting... and how many questions they have to field about things they're not still supporting, and how many questions they get for, I dunno... any program that was ever made for PC that people have trouble making run out of the box.."

    Smaller companies don't have tis problem. For most of them, all they need is a relatively short testing period to make sure itruns on Windows. Microsoft has the reverse problem : to make sure ANY legitimate programs, however poorly implimented, run out of the box whilte at the same time distinguishing between those and malicious unwanted programs. They can't cater to the smart people either. Linux has less bugs, but lets face it; even the easy to instal builds are a brain job for newbies, and impossible for most grandmothers.

    So yeah, Microsoft has a full plate, and as ugly as it sounds, I doubt its economically fesable for them to fix everything. They have to prioritize. New features= new money. New patches = no money + continued expenses.

    Conspiricy theories aside, does anyone really think they *like* having a reputation for buggy software?
  • by Zo0ok (209803) on Thursday December 01, 2005 @12:53PM (#14158549) Homepage
    I was reading a few weeks ago a MS spokesperson who answered the question why there are vulnerabilities. He said something like:


    Imagine you write a long long book. Even if you try to correct all the typos you may miss some of them. It is hard to publish a book with no typos at all.


    I think that was great fun! If MS management believes that the security problems are "typos" then I understand they cant fix them all. Of course, security problems are more like problems with the story line: contradictory events, inconsistent background and such things.


    Maybe they still have not accepted that the reason for their security problems is the poor design of Windows (particularly integrating things very freely). As long as they dont accept the truth they will try to correct typos, and that will not make the story any better.

  • by wardk (3037) on Thursday December 01, 2005 @01:18PM (#14158832) Journal
    if they "patched everything", then they would need to find an alternate source of their weekly worldwide exposure. as we know, even bad news can be good news, it's getting your name out there that's important.

    also, the constant need for patches allow them to feel they are still relevent.
  • by syukton (256348) on Thursday December 01, 2005 @01:45PM (#14159142)
    I've worked for MS in the past, in their Windows Sustained Engineering (WinSE) division. So I think I can bring some valid criticism to this situation.

    The major issue is: How many customers is it affecting? Nevermind that it's a huge security flaw with the potential to be exploited. Has it been exploited yet? If so, by whom and who was affected? If nobody has been affected, why not? These things go into determining the prioritization for a fix.

    Another slew of issues is: How many man-hours will it take to fix the bug? Can the functionality which causes the bug simply be removed without terribly ill effect? Does the person who originally wrote the code still work at Microsoft? Given the fondness for contingent staffing (aka CSG, contract workers) at Microsoft, a good number of people come and go on pretty much a 6 to 12 month basis. I know that some divisions tend to not let contract workers do development expressly for this reason, but there are always exceptions. (ie, a full-time employee (FTE) leaves the company and the company has a CSG with the skills to replace him in the interim while they hire a new FTE) Also, how many man-hours will it take to test the bug? If it will take 5,000 hours to test a bug that presently affects nobody, it ends up near the bottom of the priority list. If it will take 2,000 hours and they have a report or two from customers who have experienced the bug themselves, fixing it becomes a higher priority.

    You also have to keep in mind that Windows isn't just one program. Windows XP, for example, is XP Home, XP Pro, the new XP N (sans media player), and Windows Media Center Edition I believe is also XP-based. So that's four platforms that need a fix developed and tested. That doesn't seem like much, right? Ok, Microsoft localizes their software in 44 different languages, which will all need to be fixed and tested. Four platforms, 44 languages, that's 176 different variations which need to be fixed and tested. They will generally not release a fix for only one language at a time.

    The open-source community is filled with people with a lot of free time on their hands, as is evidenced by the fact that they are willing to do development work for free, and some of them do quite a lot of that development work. If a team of developers and a team of testers were to volunteer at Microsoft, giving their time over at no charge what-so-ever, I imagine you might see more of these bugs that don't actually affect anyone get fixed sooner. But as long as the company needs to make a risk-vs-cost analysis, bugs that don't affect anyone (yet) will not get fixed any time soon.
  • Dependecy hell (Score:3, Informative)

    by erikharrison (633719) on Thursday December 01, 2005 @02:35PM (#14159729)
    The reason MS can't patch anything is because MS has exactly the same technical challanges that every major Linux distro has. Dependency hell.

    MS likes to pretend that windows is immune to such things, but the truth is every piece of software is interconnected. MS creates the illusion of no dependency problems by solving as much of it as possible behind closed doors, and wrapping the results in binary installers. The sheer amount of effort to resolve the problem is high
  • 4 words (Score:4, Insightful)

    by smash (1351) on Thursday December 01, 2005 @05:26PM (#14161551) Homepage Journal
    Patches don't earn money.

    smash.

  • by swschrad (312009) on Thursday December 01, 2005 @08:34PM (#14162663) Homepage Journal
    MS is supporting every interface they ever sold with the exception of detail implementations of SCO Unix at the kernel level with Windows NT. that includes MS-DOS 2.10, four or five versions of windows basic runtime scripting, all kinds of stuff going back 20-plus years.

    you can't unscramble that much spaghetti code and conflicting system calls to find the hooks to fix. by contrast, any wild-eyed wobbly who wants to break in and (pick one: wreak havoc, steal credit card info, make zombies, hack spy satellites) only has to find one hole in the snakepit to let his own snakes in.

    so that's why they don't patch everything in windows. it's like counting to infinity.. just when you're almost there, somebody slams the door, and you lose count.

    Travoltus had a SIG over here a few years ago that I copied down because I liked it so much... quoting...

    63,000 bugs in the code
    63,000 bugs
    ya get 1 whacked with a service pack
    now there's 63,005 bugs in the code.

    that's where MS is at. Promoting Secure Computing, indeed. hard act to get on the road, that.
  • by rlglende (70123) on Thursday December 01, 2005 @08:44PM (#14162709)

    Windows contains above 100M lines of code (recollection from some time back, probably more now).

    The overall design philosophy is 'tight integration', so everything affects everything.

    Any software testing problem is combinatorial: all combinations of inputs checked against all outputs. This is why testing cannot be used to produce a quality product, only to check whether the development process is capable of producing a quality product.

    I guarantee you that MS's bug list for each product is in the 10s of 1000s. It is a major effort to even sort through bugs and choose the most critical, consolidate by root-cause, isolate to DLLs, AND REGRESSION-TEST THE FIX(es).

    In a large system, the overhead of source code management (checkout, change, test, merge with the release with the bug, and then merge into later releases of code) is enormous. The productivity of people doing bug fixes in these large systems is very low, no matter how expert they are. This is why developers HATE fixing problems in released code.

    No large company can fix all their bugs, even when bug fixes don't generate new bugs.

    Lew

If the facts don't fit the theory, change the facts. -- Albert Einstein

Working...