Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security IT

The Story of a Microsoft Patch 183

Posted by Zonk from the live-and-learn dept.
buckethead writes "eWeek is running a story about a security patch from Microsoft that failed to adequately address a denial-of-service flaw on CSRSS (Client/Server Runtime Server Subsystem), the user-mode part of the Win32 subsystem. It stems from a research paper from Argeniss that discusses how Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; they just added some validation code before the call to the vulnerable function, but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"
This discussion has been archived. No new comments can be posted.

The Story of a Microsoft Patch More

The Story of a Microsoft Patch

Comments Filter:

  • It's no wonder... (Score:5, Funny)

    by Anonymous Coward on Saturday October 29, 2005 @08:30AM (#13904119)
    A Microsoft Microsoft patch? That's the worst kind!

    •   A Microsoft Microsoft patch?


      Too many cooks spoil the broth.
      If there was just one Microsoft, they would have probably got
      the patch right.

      I wonder what Zonk Zonk is smoking.

    • health care coverge and the patch (Score:5, Funny)

      by goombah99 ( 560566 ) on Saturday October 29, 2005 @10:19AM (#13904423)
      Is a microsoft patch anything like one of those Nicotine patches that help you stop smoking? If so I wonder if my health care will cover it. I'd like to slap one of those on asses of my co-workers and help get them off their addiction to microsoft.

      I guess one might consider Linux to be sort of a methadone. Something that hels you with your cravings for the bad stuff, but ultimately leaves you without that satsifying high.

      Personally I useto OSX, but I'm not addicted. I could stop anytime I want to. I just don't want to that's all. Now excuse me while I watch the Genie effect a few times before I send this.
    • So bad they named it twice.

  • Liability (Score:3, Insightful)

    by VincenzoRomano ( 881055 ) on Saturday October 29, 2005 @08:31AM (#13904122) Homepage Journal
    I'm liable for bugs in my software.
    I'm not liable if my patches fail to patch the bug.
    I'm not liable if my patches make more damages than the pathced bug.
    If I do the same in restaurant business I get jailed!
    It would be great at least a "pay after use", just like pizza: do you use to pay for pizza after or before you ate it?

    • Re:Liability (Score:5, Funny)

      by Lillesvin ( 797939 ) on Saturday October 29, 2005 @08:57AM (#13904180) Homepage

      [...] just like pizza: do you use to pay for pizza after or before you ate it?

      Usually the delivery boy won't let go of the damn box until I hand him the money.

      • The trick is to pay him with what he thinks are a bunch of one dollar bills, but is really just a dollar + scrap paper.

        Then slam the door in his face & eat pizza while waiting for the cops to show up.

        Now that you've been arrested, take this opportunity to have some fun. Use your one phone call to ring up the same pizza place and order 20 or 30 pizzas to be delivered to the police station.

        Laugh!
        (and hope they give you a slice or two))

    • I usually eat pizza in restaurants, hence I pay after eating it.

      However, software is not (At least traditionally) something capable of expiring, thus I expect to pay before before use. Would you expect to pay for a car before or after you clock up 10,000 miles?
    • just like pizza: do you use to pay for pizza after or before you ate it?

      As you might know Pizza is of Italian origin.
      In many, probably most, Italian road side eateries you do indeed pay first, eat later.

      • Strange, all the many many times I have spent in a Pizzeria, I distinctly remember paying after eating. This was both at La Terazza in Poggio dei Pini, at Maddalena Spiaggia, an outfit on Via Roma in Cagliari and at a Pizzeria in Rome on God-knows-what-street.

        I don't know what you're talking about. ``American Pizza'' may be Italian in origin, but it's an insult to claim it to have anything to do with real Italian pizza.
        • Read my post, I talk about road side eateries not 'regular' restaurants.
          Next time you're in the country try getting something at the airport or an 'Autogrill' type autostrada restaurant.

          However, I DO agree with your differentiation between the Italian Pizza and the American derivative.

    • Literally, 'irresponsible' means 'not responsible', and Microsoft's EULAs require that you absolve them for all responsibility for their bugs (and bug fixes), so they're really not responsible for fixing your bugs. They just do it for the PR value ...

      and PR is all about appearances.

  • Stuttering in the summaries? "It stems from a research paper from Argeniss that discusses how Microsoft Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; ...... but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"

  • Symptoms vs Causes (Score:2, Insightful)

    by klingens ( 147173 )
    Cue all the "Microsoft doesn't remove the causes of bugs but only fixes symptoms" comments

  • Why didn't tehy fix it right in the first place? (Score:4, Insightful)

    by Barkley44 ( 919010 ) on Saturday October 29, 2005 @08:34AM (#13904129) Homepage
    Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.

    • Re:Why didn't tehy fix it right in the first place (Score:4, Insightful)

      by The Lerneaen Hydra ( 885793 ) on Saturday October 29, 2005 @08:51AM (#13904167)
      Maybe because they didn't really care about the other ways to get in, but all they cared about in this case was their image to the outer world, and thereby being able to say "See, look at us, we patch our flaws immediately".

      • Re:Why didn't tehy fix it right in the first place (Score:1, Insightful)

        by Anonymous Coward
        This is a valid approach, if the hole was being exploited by script kiddies or an automated worm. If your system was being DOSed, you would take the quickfix rather than waiting two weeks for the proper one.

    • Re:Why didn't tehy fix it right in the first place (Score:5, Informative)

      by daern ( 526012 ) on Saturday October 29, 2005 @08:52AM (#13904168)

      Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.

      One possible reason is that changing the code to make it "safe" would have broken application compatability. I would be very surprised if this was not the reason...

      This would explain why, instead of fixing the underlying problem, they chose to wrap it in validation to reduce the risk. It sounds like they did not do a complete analysis of the problem, but I think that's a method problem rather than a rundamental flaw in how they fixed it.

    • Re:Why didn't tehy fix it right in the first place (Score:5, Interesting)

      by Xugumad ( 39311 ) on Saturday October 29, 2005 @09:36AM (#13904270)
      As a developer, there are times we'll just gloss over a security problem to get the worst of it fixed ASAP with the least risk of breaking something else in the progress (and there are also holes that I'm desperately hoping no-one finds before I have time to completely rewrite the code, and beat to death the programmer responsible for it in the first place, but that's a rant for another day).

      It's possible that the first fix was just a temporary measure they knew wouldn't break anything else, while they rewrote the problem function and put it through proper testing. On the other hand, this is Microsoft, so I may be being overgenerous here...

    • Re:Why didn't tehy fix it right in the first place (Score:5, Insightful)

      by dlasley ( 221447 ) on Saturday October 29, 2005 @09:45AM (#13904308) Homepage
      One must also consider the possibility that the folks doing the coding and the quality assurance (SQA) may not be the original authors of the specific branch involved, and therefore did not have the proper experience level required to do the research and make the judgement calls. With the rumored turnover Microsoft has seen lately, I wonder if this is not a possibility?

      More and more of the post-development activities (break/fix, SQA, implementation/packaging, etc.) for software are happening in little bubbles, somewhat removed from the core competency group that created the original code. We even see this touted as the right way to do things [itil.co.uk] from sources that are considered to experts in the process + workflow arena (well, some folks consider them experts, anyway). When this becomes the standard operating procedure, any company runs the risk of bad patches to any kind of software: you can not limit the culpability to Microsoft.
      • Whether or not the coder writing the patch was the original author of the code has little to do with his or her ability to write a good patch. The few times I have asked the original author for some insight on a function I need to update, they haven't had anything useful to contribute. The problem is that usually the original author hasn't looked at the code in over a year. Personally, if I haven't looked at code in the last month, someone else may as well have written it because it is no longer fresh in

  • unpatchable (Score:3, Interesting)

    by Anonymous Coward on Saturday October 29, 2005 @08:34AM (#13904131)
    As Microsoft have "intergrated" all their api's into one core buggy OS it doesnt suprise me. Fixing the actual function would probably crash loads of others. But hey thats the microsoft way..

    Frankly it would be better if they started over again.. Look at the situation now.. even M$ themselves have to create infect a machine to track down spammers instead of fixing the root problem. Its like an aircraft with Gaffer Tape holding it together (with a paint job to make it look cool in new version of windows vXXX).. and they couldnt blame weather ..

    I also feel really sorry for m$ coders.. they have a lot of talent but they are probably in a situation where they dont want to mess with code too much as changing things will bring the whole system down.. and a lot of chair throwing.

    As Ballmer is a coder himself maybe he should join the troops in the basement and get to the fix and a steady system. Only them will users believe that Wind is a truly great system. At the moment m$ are in denial.

  • Is this really that bad? (Score:5, Insightful)

    by ebob9 ( 726509 ) * on Saturday October 29, 2005 @08:35AM (#13904133)
    The article criticizes Microsoft for not fully understanding the vulnerability, and issuing an incomplete patch.

    I understand that in a best case scenario, a vendor should release a 100% effective patch. However, in reality, that's not always going to be the case.

    Microsoft released a patch that stopped the public vulnerable attack vector. Then, once they were alerted that they didn't fix all possible vectors, they issued a new patch (albeit quite a few months later).

    With the large amount of bugs and vulnerabilities that a software behemoth like Windows is going to have, is it really that unthinkable that an incomplete first-patch would be released? I'd wager that even OSS products routinely have incomplete first-patches.

    • Re:Is this really that bad? (Score:5, Insightful)

      by QuietLagoon ( 813062 ) on Saturday October 29, 2005 @08:43AM (#13904148)
      Yes, this is really that bad. Software development is supposed to be Microsoft's core competency. That they are not knowledgeable enough to patch the root cause instead of the symptom speaks volumes of their incompetence in their supposed core competence.

      The first question I'd now ask is what other symptoms have been patched which have left other vulnerabilities open for exploit via other attack vectors?

      • Re:Is this really that bad? (Score:5, Insightful)

        by Metroid72 ( 654017 ) on Saturday October 29, 2005 @09:37AM (#13904276)
        Just to be clear from the begining: I don't disagree with you.
        Your underlying assumption is that Microsoft's core competency is software development, however, I think that's debatable. Over the years they've demostrated that they are a better Marketing company than a software development company.

        They happen to be very fast to identify consumer needs or technology trends (either by researching or copying others) and integrate them quickly in their product portfolio. I think that aggresive way to integrate new features tends to help a lot in writing bad code.

        It's not until lately, due to the size of the company and layers of bureocracy that MS is having a tough time releasing products and features to market quick enough. Since the birth of the internet they have been very reactive, but now it's taking them longer to react to the market realities and trends.
        • Your underlying assumption is that Microsoft's core competency is software development

          Actually, if you re-read his comment, he says that software is supposed to be their core competancy, not that it actually is.

          And for the record, this is not the first time this has happened - am I the only one who remembers the directory traversal unicode exploits in IIS?
        • Your underlying assumption is that Microsoft's core competency is software development, however, I think that's debatable. Over the years they've demostrated that they are a better Marketing company than a software development company.

          One could also debate that the core competency is legalities, i.e., pushing the limits of the law to leverage an illegal monopoly. :-)

          I agree with your comment.

    • Bugger. My mod points expired.

      That's the most sensible and balanced Microsoft-related post I've read in quite a while.

    • Re:Is this really that bad? (Score:5, Insightful)

      by SharpFang ( 651121 ) on Saturday October 29, 2005 @10:06AM (#13904382) Homepage Journal
      It's okay to release a "quick and dirty fix" immediately. Like Firefox, disabling whole feature that is vulnerable. But they shouldn't need to be told the fix isn't good. They should start working on a full, proper patch as soon as the hotfix is ready, and be aware WHAT the vulnerablity is. Put a band-aid on the bleeding wound right after the accident, okay, but then let the surgeon remove splinters and sew the skin together properly once the patient arrives at the hospital. Don't leave as-is because it's not bleeding at the moment.
      • Your mentioning of Firefox made me think of how boring it is for a Mozilla dev to go back and even look at the 1.0 Aviary branch let alone patch it for some random "security vulnerability" that was fixed ages ago on the pre-1.5 branch. Microsoft is usually working on their new products, and going back to continue working on severely outdated branches to fix a few problems can sometimes feel like a waste of time the closer you get to launching the next big version. I guess the big difference here is that M
        • The annoying pitfalls of developing a massive project and randomly having to go back and fix small or large things in 10+ month old code
          Is it so wrong for millions of customers to expect service for a product they've shelled out good hard-earned money for?
          • In a perfect world, you'd be able to get the updates to the product you bought for free. When you can't, the developers have to continue support for old versions for a reasonable amount of time. Which is more costly: give free updates (nobody needs to continue buying new versions) or continue support/development on old versions (requires more time and developers)?

  • Movie Deal (Score:5, Funny)

    by jettoki ( 894493 ) on Saturday October 29, 2005 @08:37AM (#13904139)
    From TFA:
    It's being called the "story of a dumb patch."

    Soon to be a 200-part epic, starring John Goodman as Steve Balmer.
    Coming to a Windows Vista box near you!

  • Great... (Score:3, Insightful)

    by ninja_assault_kitten ( 883141 ) on Saturday October 29, 2005 @08:40AM (#13904144)
    Now we get to listen hundreds of people who's programming experience consists of 5000 lines or C/Perl/Python tell everyone what the proper process is for matching vulnerable code.

    • Re:Great... (Score:5, Insightful)

      by Taladar ( 717494 ) on Saturday October 29, 2005 @08:50AM (#13904164)
      The proper process actually is not to write tightly coupled modules bigger than the size one person can know completely. It is well known by now that software development is too complicated if you write several million line programs without dividing them in a way that makes them more similar to a large number of small, separate programs.
    • Translation: "I'm going to defend Microsoft on Slashdot to get karma (it makes you look enlightened and individual to moderators), so in an article where Microsoft was clearly caught with their pants down, I'm going to instead distract the issue by mocking the coding experience of some of the commenters, as if that has anything to do with the #1 software company in the world not getting the 'software' part right. It's kind of like telling movie reviewers who've never made a movie before that they can't cr

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

    by b3x ( 586838 ) on Saturday October 29, 2005 @08:44AM (#13904152) Journal
    At least they tried! And mommy says thats what counts.

  • The Story of a Microsoft Patch (Score:5, Funny)

    by AthenianGadfly ( 798721 ) on Saturday October 29, 2005 @08:45AM (#13904154)
    The Story of a Microsoft Patch
    A Tragedy in Three Acts

  • Security and the stock price (Score:5, Insightful)

    by ewg ( 158266 ) on Saturday October 29, 2005 @08:49AM (#13904160)
    Has any Windows security problem ever hurt Microsoft's stock price?

    I checked MSFT a couple of times when mail-based malware was running amok, seriously enough to reach the general news media. No effect.

    If that's the overall pattern when it comes to Microsoft security issues and Microsoft's business success, it goes a long way toward explaining security missteps like MS05-018. There's no direct incentive for them to master security.
    • ...So long as the malware doesn't affect the sales. And it won't affect the sales unless there's a better looking competitor, either because Microsoft aren't patching quickly enough or the quality of the competitors (read: Linux distributions, in general) improve in the eyes of the public to the point where they can compete. Microsoft hasn't needed to worry about the second much since the last time it was competing with other mainstream (such as the Apple OSes, early in the game), but the first has always r
    • People take it for granted that Windows won't work. The average person will call upon a neighbourhood geek before they talk to MS about a problem. This shows that either people aren't even thinking of blaming MS for the problems (they figure problems are actually normal!), or they have no confidence in MS in fixing the problem.
      • Or they just think that they really understand nothing about computers and that they'd better call their friend who seems to talk with them as if they were human or something.
        I mean, nowadays most people who use computers at home really don't understand the slighest thing about them. If they have to use it without help, they'd really be better off with a mac. (And i've nearly never used a mac in my life, but they're clearly ok for people won't know nothing about computers. They don't suppose that you kno

    • Has any Windows security problem ever hurt Microsoft's stock price?

      If it does, the stock price might actually go up. Companies will buy another ISA server to protect the server from its defects. Of course, Microsoft marketing does not factor in these costs to TCO. CIOs are technically backwards people but like the familiarity of a Windows screen so they buy readily into more Microsoft.

      Only Microsoft could get away with producing the problem, make itself look like a hero for fixing or mitigating it and

    • Re:Security and the stock price (Score:4, Insightful)

      by Overly Critical Guy ( 663429 ) on Saturday October 29, 2005 @12:41PM (#13904913)
      MSFT's stock price has been flat for five years at ~$25. Maybe that's the hurt.

  • Monolithic design of CSRSS is to blame here... (Score:4, Informative)

    by nick8325 ( 825464 ) on Saturday October 29, 2005 @09:08AM (#13904210)
    The problem, as far as I can see, is that CSRSS.exe, which implements some important parts of win32 (important enough for the kernel to die in sympathy if CSRSS dies), is also responsible for the menial tasks of drawing console windows.

    If the code to draw console windows were in a separate, unprivileged process, or even better a library, this bug would not be particularly exploitable. The worst DoS possible would be to prevent anyone from making console windows until the process was restarted.

    There was another console bug a few years ago, see here [google.co.uk]. Printing a few tabs and backspaces to the console would cause the machine to blue screen.
    • It always struck me as odd, the way the console window appears to be a part of the system instead of a separate executable, but I guess it has to do with the way DOS emulation works "seamlessly", i.e. just run the .exe and a console window appears for it. I suppose the system X11 uses, where if you need the text output of a program, you run it in a terminal emulator, is too difficult for users or something...
    • If i recall this is the same bug. Details can be had here http://homepages.tesco.net./~J.deBoynePollard/FGA/ csrss-backspace-bug.html/ [homepages.tesco.net] This has been around since NT 3.51 and is directly related on how the console handles High-level I/O.

    • Re:Monolithic design of CSRSS is to blame here... (Score:4, Interesting)

      by Foolhardy ( 664051 ) <`csmith32' `at' `gmail.com'> on Saturday October 29, 2005 @02:57PM (#13905531)
      The problem, as far as I can see, is that CSRSS.exe, which implements some important parts of win32 (important enough for the kernel to die in sympathy if CSRSS dies), is also responsible for the menial tasks of drawing console windows.
      I think that CSR was intended to be a generic subsystem server at one point. CSR actually loads libraries that contain the work code: from HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems, Windows value
      %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
      This is the command line used to start csrss. Note the ServerDll= lines: csr loads basesrv, winsrv and calls entry point UserServerDllInitialization and ConServerDllInitialization. Csrss.exe is only some 6KB: the real work is done in these libraries. Back when Win32 was all in user mode (NT 3.51) winsrv.dll was 1.3MB: it's where all the GDI and USER back end code lived. There was also a call to GdiServerDllInitialization in winsrv. In NT4 winsrv.dll shrunk down to 166KB, since most of the code was moved into win32k.sys. Anyways, it looks like the console is implemented in winsrv but using the ConServer init function; it might be (or have been) possible to have CSR start another unpriviliged process that just does the console work. I bet MS could do it if they really wanted to.

  • As if the patch woes are not enough..., (Score:4, Interesting)

    by bogaboga ( 793279 ) on Saturday October 29, 2005 @09:08AM (#13904213)
    ...in my case, I have found that the total disk space consumed by Windows 2000 patches is bigger than the original Windows 2000 install itself! To make matters worse, I am now very low on disk space. I console myself by the fact that disk drives are cheaper nowadays. Whether these patches actually work as advertised is an open question, but I have my doubts though. All I see are a bunch of Hot Fix entries and nothing more.

  • IBM isn't any better (Score:5, Informative)

    by MS ( 18681 ) on Saturday October 29, 2005 @09:09AM (#13904217)
    5 years ago one of my clients bought IBM Net.Commerce. While adapting the scripts to their needs, I found a vulnerability, witch exposed configuration data (passwords included) via HTTP: you simply had to add a dot to the filename to view it in the browser.

    We decided to tell IBM, and they patched it. But not fully: the same hole was still open. It was not anymoe possible to access the configuration data by appending a dot, but this time is was enough to add a "%20" to the filename or something similar.

    Instead of moving those configuration files out of the webroot!

    :-(

    • witch exposed configuration data

      Ah ha, I knew the black hat meant something - hackers are witches! Obviously the problem was that they didn't protect their data from being read in hex-idecimal.

  • So? (Score:3, Insightful)

    by kevin_conaway ( 585204 ) on Saturday October 29, 2005 @09:19AM (#13904236) Homepage
    There is always going to be the same fundamental flaw in software development: humans.

    Humans write the original code that produces bugs. Other humans (who may or may not fully understand the code they're working on because the original developer left the company) write patches to fix those bugs and in the process of doing so, create new ones.

    Its the nature of the beast, it happens everywhere. Don't get me wrong, Microsofts overall record is pretty weak and I think they have made some serious design flaws with their OS, but to write a whole article on one bugfix smells a little like flamebait to me.

  • ./sigh (Score:3, Insightful)

    by AcheronHades ( 837485 ) on Saturday October 29, 2005 @09:22AM (#13904239)
    A Microsoft bashing story on Slashdot??
    • Did you RTFA?

      I know it's hip and cool to defend Microsoft for karma purposes, but the criticism is warranted. This is the top software company in the world whose software several country's economy's rely on. Yet the research paper shows they didn't do proper investigation, leading to two patches months apart instead of one.

      How did the American economy come to rely on something so...unreliable?

  • Binary compatibility (Score:4, Insightful)

    by LaughingCoder ( 914424 ) on Saturday October 29, 2005 @09:39AM (#13904284)
    Here is an example, perhaps, where FOSS has an advantage. Microsoft might not be able to fix the function because it is "in the wild" and there could be many dependent "already-compiled" applications which would/could be affected. In the FOSS world where backwards binary compatibility is not an issue, a source patch could be made available. Oftentimes the way these sorts of problems are handled by Microsoft is they roll out a new updated API, leaving the old ones in place. This obviously doesn't address the installed base of buggy code, but fixes the problem going forward - assuming they can convince the developers to adopt the new API. Unfortunately, this course of action is also not applicable to a security patch scenario. So, MS issues an imperfect patch addressing, hopefully, the most flagrant problems, and queues the function as one needing to be deprecated in a future release.
    • Changing behavior isn't that feasible, even if you have access to all application sources? Do you want a minor patch to X.org or even the kernel break your existing setup, no matter how easy the fix to get those too working again might be?

      Anyway, what you are saying about just introducing new APIs in patches is basically false. They wouldn't be patches if that's what they do. True, some APIs are basically deprecated while still supported, for security reasons. A rare few have been completely retired or tur

      • Anyway, what you are saying about just introducing new APIs in patches is basically false. They wouldn't be patches if that's what they do.

        Actually, quoting my own comment:

        Unfortunately, this course of action is also not applicable to a security patch scenario

        So I guess we have a case of violent agreement?
    • "In the FOSS world where backwards binary compatibility is not an issue, a source patch could be made available."

      BULLSHIT. Lack of backwards binary compatibility is the reason that NVIDIA and ATI have to resort to dirty hacks to release their drivers for Linux.

      Backwards binary compatibility means that a hardware vendor can release one binary driver, without having to worry about whether it will work next month. It's not reasonable to expect every hardware company to want to release every module - but with L

  • Hey, its Micorosoft. This is what they do... (Score:5, Insightful)

    by sjanes71 ( 2217 ) <simon.janes@gmail.com> on Saturday October 29, 2005 @09:43AM (#13904300)
    They have lots of practice at it. Practice at what? They disclaim or disable the user to death. Instead of fixing the holes, they pop a dialog window and confuse the user. "Hey, some program is accessing your address book!" "You're about to enable file or printer sharing, are you sure that you want to do that? Someoone might, uh... get some files or use your printer over the network." "You're not allowed to open attachments until you find this one little checkbox and click it before we let you open attachments, because we think you're stupid." Everyone of these little dialogs is a tiny micro-EULA that users never quite read or understand.

    This happens over and over and over again— with some users, I'm afraid to upgrade their software because their "world" sadly depends on the cargo cult execution of gestures to get their work done. Too many applications change how they look and feel with every upgrade that many users go off the rails whenever that happens. At least with an application, you can kind of avoid it, but when it's Windows— aw man, why not just fix the SECURITY HOLES instead of changing the UI? Please, Microsoft?

    Screw it [sic; I'm being polite.], I'll keep my Mac OS X [apple.com] for clients and Gentoo Linux [gentoo.org] for servers and any web service that doesn't suck (Gmail [gmail.com], Basecamp [basecamphq.com], etc.), thank you very much.

    Microsoft's days are over the moment Google decides to market an operating system that includes GFS [google.com] for redundant data-storage and their MapReduce [google.com] for batch processing. These things are big contributors to how its even possible for Google to exist. Simplicity trumps mediocrity.

    • That's why MS does this.

      You can have all the protection you want and it doesn't help if the user thwarts it. The user owns the machine, they have ultimate control. They are not going to put up with not being allowed to do things like open attachments. So they have to do their best to educate the users and give them a chance to not screw themselves.

      You have very little grasp of the problems involved in trying to make a machine secure without the owner's cooperation.

    • This happens over and over and over again-- with some users, I'm afraid to upgrade their software because their "world" sadly depends on the cargo cult execution of gestures to get their work done.

      I would have thought this was an exaguration if it hadn't happened to me. I was helping a user fix a problem on her PC, and she was lost because the icon that started the program had moved on her desktop.

      It's bizzare. If I moved your stapler from the left side of your desk to the right, would you call help desk?

  • Deja vu (Score:5, Funny)

    by HangingChad ( 677530 ) on Saturday October 29, 2005 @09:53AM (#13904338) Homepage
    Microsoft Microsoft only patched one path to the vulnerable function

    It's a glitch in the Matrix. It usually means they've changed something...

  • I attended a data security meeting held at the university where I work. We had a guest speaker from Microsoft who spoke on the subject of security. Microsoft is attempting to release security patches more often because their patches are being reverse-engineered in under two hours. The speaker also mentioned that an organization needs to respond to security threats in a more agile manner. On a side note, Microsoft is using agile software practices. Is it possible that they have misunderstood the agile mantra
    • Microsoft has been saying this for years, i attended a talk by microsoft security 3 or 4 years ago where they claimed the same thing.

      However, they didn't offer any kind of proof that these two hour reverse engineers actually occured two hours AFTER the patch release, the best they could do is say the code became PUBLICLY available two hours after the patch release.

      If you have code that exploits a vulnerability, as long as everyone is quite about it you're free to exploit for your own purposes. Once a patch

  • Exercise (Score:3, Informative)

    by fatphuk ( 926882 ) on Saturday October 29, 2005 @12:21PM (#13904831)
    For those of working on any windows app, if possible, as an experiment put your app through some memory leak detection software (like Purify etc). I'm sure you'll be as shocked as I was to see how many OS level buffer overflows are happening at any given time. There's so many of them that it makes sense, from a cost perspective, why MS simply fixes the ones that matter as they come up.

  • Remember This Story (Score:5, Insightful)

    by bfree ( 113420 ) on Saturday October 29, 2005 @12:51PM (#13904950)
    The next time MS claims it fixes security holes faster then anyone else ...

  • The moral of the story: always patch the vulnerable function or at least patch all paths to vulnerable function.

    All paths?!?!

    How do we know in the future that this function won't be used again in something/somewhere else? Since we all know how "wonderful" M$ is at documentation, how many here think that there'll be a note in there that specifies something extra that needs to be done before the call to that function. Talk about wasted time/money.

    You patch the function that needs to be patched,

  • http://216.239.59.104/search?q=cache:xSevAZ0lKYEJ: www.argeniss.com/research/MSBugPaper.pdf+&hl=en&cl ient=firefox-a [216.239.59.104]

    seems that whoever was running the server that paper was on pulled it presumablly because of the /.ing

Slashdot Top Deals

E = MC ** 2 +- 3db

Close