Slashdot Mirror


Time to End Microsoft's Patch Tuesday?

buzzardsbay writes "Techtarget's resident security curmudgeon, Dennis Fisher, is calling for an end to Microsoft's monthly security patching cycle. Fisher points out that 'a hacker only needs one unpatched system, one little crack in the fence in order to launch a major attack on a given network. The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.'"

256 comments

  1. I have always wondered... by AxemRed · · Score: 4, Interesting

    Why don't they just release patches as the make them? Is there a specific reason that they hold them all until "patch Tuesday?"

    1. Re:I have always wondered... by Pentavirate · · Score: 2, Insightful

      So your machine only reboots on you when you're not looking once a month instead of every single day!

    2. Re:I have always wondered... by kcurtis · · Score: 5, Insightful

      It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

      If the updates come out on a random schedule, as done before, you cannot plan ahead for the testing required to ensure the updates don't break functionality.

    3. Re:I have always wondered... by kjkeefe · · Score: 1

      Probably just an old hang over from pre-Internet patch distribution methods... There's no excuse for them not to get with the times...

      --
      1, 2, 3, 4, 5... That's the combination on my luggage!
    4. Re:I have always wondered... by Anonymous Coward · · Score: 0

      They need this time to develop the next backdoor and slip it into the updates.

    5. Re:I have always wondered... by OECD · · Score: 1

      Why don't they just release patches as the make them? Is there a specific reason that they hold them all until "patch Tuesday?"

      My guess is precisely to keep it a manageable, once a month job. I don't see how a patch-a-day is going to make IT's life any easier (although it would be a good excuse to hire more staff.)

      --
      One man's -1 Flamebait is another man's +5 Funny.
    6. Re:I have always wondered... by ECS_Norway · · Score: 1

      I believe patches need a little time to be tested. I think it makes it easier for IT departments to get some sort of coherent schedule on patching machines. It also helps give some for some sort of press to critical patches. It would be hard for the average Tech to keep up with a slew of patches at anytime. But, as the article points out, there are big problems with the once a month system.

    7. Re:I have always wondered... by rob1980 · · Score: 1

      If things are going to blow up, you might as well have it all happen on one day of the week/month/whatever - as every time somebody decides to patch something.

    8. Re:I have always wondered... by Rolgar · · Score: 1

      For system administrators, it allows them to only have to address patching Windows machines once a month. If they can do all of the testing, and roll all of the patches out in one go, then it makes using Windows less of a burden by reducing duplicated effort.

      On the other hand, if you're a Microsoft hater, you might think Microsoft is using this to hide how many vulnerabilities Windows has. If users had to reboot 7 times for this week's patches over the course of a month instead of just once a month, they might decide that maybe Windows isn't secure enough and look at alternatives. If you only have to reboot occasionally, it's routine maintenance, but frequent reboots might raise flags in the minds of home users.

    9. Re:I have always wondered... by ben+there... · · Score: 1

      So your machine only reboots on you when you're not looking once a month instead of every single day!

      That pissed me off a couple days ago. I had stuff downloading overnight and scheduled SageTV recordings that got interrupted. I woke up to my computer at the login screen and thought the power must have gone out. Then the friendly green shield kindly informed me that it rebooted without my permission.

      That's the cue for me to disable the Automatic Updates service. The idea is good but the implementation is awful.
    10. Re:I have always wondered... by symbolset · · Score: 1

      Because om black wednesday when your clients start complaining about service failed to start and intermittent memory errors, you know to look for the toxic patch first rather than the more usual virus. Saves a ton of diagnostic time.

      --
      Help stamp out iliturcy.
    11. Re:I have always wondered... by Professor_UNIX · · Score: 1, Insightful

      For system administrators, it allows them to only have to address patching Windows machines once a month.
      This is a stupid idea though. It saves the administrators some hassle, but if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it? Why should I have to wait a month for a patch to a critical vulnerability just because some company's IT department only wants to work one day a month on patching? Patches should be released as soon as possible for anything critical or security-related and you can let companies choose to sit on them for a month if they want.
    12. Re:I have always wondered... by binner1 · · Score: 1

      Or...you could just tweak the setting so that it applies patches but waits for permission to reboot. Group Policy (gpedit.msc) somewhere...

      Not perfect, but it seems a best of breed given the available options.

      -Ben

    13. Re:I have always wondered... by Score+Whore · · Score: 1

      Hell, I'm running XP Home and only went to the extent of saying "notify me of patches, but don't download or install them." It pops up the balloon saying "we got patches for you" and then I can choose when to download and install. It doesn't take much in the way of rupert science.

    14. Re:I have always wondered... by Feyr · · Score: 1

      at least you were greeted by the login screen. i had one "reboot" for patches, except it didnt reboot, it SHUTDOWN. very nice when you want to use it remotely

    15. Re:I have always wondered... by jimicus · · Score: 1

      Does Windows gracefully handle the situation where a DLL which is currently in use is replaced, or will I wind up with applications calling two different versions of the DLL depending on when they started?

      Because if it's the latter, no thanks. I'd rather download the updates so they're quick to apply, then do the actual application on my own terms.

    16. Re:I have always wondered... by Steendor · · Score: 1

      XP Pro SP2, 2K3, and presumably Vista --- The control panel lets you specify that you don't want it to install until you're ready. No auto-install -> no auto-reboot. Group policy settings go beyond that and let you schedule the auto-reboot, among other things: Computer Configuration\Administrative Templates\Windows Components\Windows Update

    17. Re:I have always wondered... by Martin+Blank · · Score: 1

      Every company I've been at over the last decade has been stretched on resources, and my current employer much moreso than any before. While I have some additional control over systems that are my responsibility, and will apply updates as I find them, we have numerous fragile applications that have to be carefully managed in shutdown and restart, and they can take from five to fifteen minutes per system of engineer time in coaxing through a proper patch, shutdown, and restart. Spread this over several hundred systems, and that's a lot of time that engineers don't often have -- and usually after hours, since most of the systems are not permitted to be shut down during business hours. We're looking at solutions like WSUS, but the ironic twist is that no one has the time to devote to it to ensure that it's properly done.

      There are much larger networks than mine, and some of them even more fragile. Microsoft was blasted for releasing scattershot patches before, and since the change, they've been blasted for releasing them once a month (with the occasional super-critical patch released off-schedule). No matter which way they do things, they're going to have half of the industry mad at them. Better to go with the one that makes their lives easier.

      --
      You can never go home again... but I guess you can shop there.
    18. Re:I have always wondered... by Score+Whore · · Score: 0, Flamebait

      As long as you don't mind working nights. There's no way an enterprise is going to accept daily, business hours outages.

    19. Re:I have always wondered... by Matt+Perry · · Score: 4, Insightful

      It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

      If the updates come out on a random schedule, as done before, you cannot plan ahead for the testing required to ensure the updates don't break functionality.
      Nonsense. Companies are free to test and upgrade on a given day no matter when updates come out. I test patches and update my Linux servers once a month even though patches for said machines may come out at any point in time between my patch days. I make exceptions to this only for patches that we deem critical enough to apply outside of our schedule.
      --
      Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
    20. Re:I have always wondered... by Hatta · · Score: 1

      Obviously you don't have to install the updates as soon as they're posted. Just pick a day a month to do it all. Of course you'll be vulnerable the rest of the month, but that's no worse than it was when microsoft held the patches.

      --
      Give me Classic Slashdot or give me death!
    21. Re:I have always wondered... by rblancarte · · Score: 1

      As someone who does regularly patch their windows systems, but pays ZERO attention to the schedule, does MS follow this Patch Tuesday rule for only IT or for EVERYONE?

      If this is an everyone issue, then IMHO, Patch Tuesday makes no sense. Because some IT don't want to work (stop me if you've heard that one before), they are halting the deployment of patches to the whole populace? IMHO, not smart.

      Of course, I could be wrong about this, if so, please enlighten me.

      RonB

      --
      It is human nature to take shortcuts in thinking.
    22. Re:I have always wondered... by Anonymous Coward · · Score: 0

      If they're already a Microsoft shop, they're used to it.

    23. Re:I have always wondered... by Score+Whore · · Score: 1

      This is a stupid idea though. It saves the administrators some hassle, but if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it?


      That's a nonsensical argument. You could make the same argument for any piece of software at anytime. So it's a useless factor in your analysis of the criticality of the particular issues addressed by any particular patch.

      Each individual user should be deciding how important a particular patch is. For the vast majority of consumers this is pretty much impossible. For them it makes plenty of sense for Microsoft to establish the patching process and schedule, eg. to provide a service that a business IT department would typically provide.

      For businesses, again, it's up to them to determine what their exposure happens to be for each software application and OS. There's no way that a statement can be made that is relevant to industry as a whole.
    24. Re:I have always wondered... by binner1 · · Score: 1

      Renaming of replacement files happens at boot...windows can't delete open files like unix can, thus the new dll's can't be put in place until reboot. You should be safe in that regard. If windows is able to swap the file, then nothing is currently using it.

      -Ben

    25. Re:I have always wondered... by LurkerXXX · · Score: 4, Insightful

      You always wondered? You must be fairly new to IT. MS switched to that format well within the past 10 years. I think it was around 5 years ago. Before that they released them as each was finished.

      As for why they do them that way now, their large corporate customers asked them to. In large corporate settings there are often lots and lots of in-house-developed applications the company runs. Each time a new patch comes out, the IT dept must go through a lengthy (sometimes several weeks) process of testing the new patch, on test beds of the various models/configurations of computers the company uses, to make sure it doesn't break any of those apps, or any other purchased applications. They often run into many bugs/conflicts that MS doesn't in their testing.

      If MS comes out with a patch, the company starts testing it out, then 3 days later MS comes out with another patch, the big corp now has multiple cycles of testing trying to go on at the same time, using up tons of IT resources, backing things up in the pipeline. If their testing cycle is 2 weeks, and MS releases 6 patches during those two weeks, the pipeline is now filled up with 12 weeks worth of throughput. Not fun.

      If, on the other hand, MS releases on a regularly scheduled day each month, the company can easily run their test suite just a single time, freeing up IT resources, and also letting them plan for the patches/testing, rather than being surprised and having to pull folks off of other projects to work on testing if MS suddenly goes on a streak of releasing several patches in a row.

    26. Re:I have always wondered... by AxemRed · · Score: 1

      IT departments could still stick to a schedule though... They could apply all available updates once a month just like they do now. If a vulnerability is fixed a week after they usually do the updates, any IT department that wants to stick to a schedule can always ignore the patch until their next scheduled update.

      I have seen one example of how this could work at a university where I used to be employed. They disabled automatic Windows updates by default, and they had some 3rd party software that pushed out the updates instead. After Microsoft released updates, they would evaluate them to make sure they wouldn't break anything. Then they would push out the updates later. It wouldn't have really affected them if they updates were released one at a time as opposed to all at once.

    27. Re:I have always wondered... by Joebert · · Score: 1

      You just didn't have it configured the way you needed it to be, your error, not Microsofts.

      Configure it to inform you but not automaticly download them & quit blaming your mistakes on Microsoft.

      --
      Wanna fight ? Bend over, stick your head up your ass, and fight for air.
    28. Re:I have always wondered... by LocoMan · · Score: 1

      To be fair, it is worse because before it was a month where (in the best case) only microsoft knew of the patches, while then it would be a month that crackers had to reverse engineer the patches, find out what the vulnerability was, and take advantage of yet unpatched computers.

      Then again, since most home users don't update their computers as it is, that's what's happening already.

    29. Re:I have always wondered... by LocoMan · · Score: 1

      This is that sometimes first time a vulnerability becomes public knowledge is when the patch comes out and it's reverse engineered... so if you release patches first to home users and on patch tuesday to corporate ones, you put them more at risk.

    30. Re:I have always wondered... by SeaFox · · Score: 1

      It would more obvious to Windows users how insecure the product is if they made patches available as soon as they wrote them. Installing 5 patches at once has less negetive PR-effect that installing a different patch at 5 different times.

      I've heard people who say they don't update because they get sick of downloading patches, don't think they are of that much importance, etc. Maybe its because almost all the patches are for "critical venerabilities". It's like crying wolf after awhile. The term becomes meaningless because it happens so often. The joke here is it's not crying wolf, all those venerabilities really do have security risks.

    31. Re:I have always wondered... by ben+there... · · Score: 1

      Thanks, but I have XP Home. gpedit.msc and the Security tab on files are all I would need from Pro. Unfortunately, I didn't give MS that much money for all the other stuff I don't need. Sounds like your solution would have worked best though.

      I really just want it to install everything. Only thing I don't like is the reboots. Should really be clearly visible option in the AU panel. Thanks for your help. Can't believe some of the other responses I've gotten though...

    32. Re:I have always wondered... by BrewedInTexas · · Score: 1

      You just didn't have it configured the way you needed it to be, your error, not Microsofts.
      So it's my fault that Microsoft has a crappy default setting?
    33. Re:I have always wondered... by BrewedInTexas · · Score: 1

      This is radical thinking I know, but check this out. If you like the once a month patches, just apply them once a month. Personally, I'ld like to get them as soon as possible. If your financial records are stolen because the patch wasn't released, just remember which side you were on and don't blame me.

    34. Re:I have always wondered... by Joebert · · Score: 2, Insightful

      No, it's your fault that you didn't learn how to configure your system to meet your needs. :)

      --
      Wanna fight ? Bend over, stick your head up your ass, and fight for air.
    35. Re:I have always wondered... by ben+there... · · Score: 1

      Configure it to inform you but not automaticly download them & quit blaming your mistakes on Microsoft.

      That's not really what I want. I don't want to be nagged. It's not really "automatic" then, right? And I don't want the nag yellow shield in the tray all the time. I just want some decent configuration options for it, like "just fscking do it and quit bothering and interrupting me". Guess if you have Pro and open gpedit.msc and hack some options you can get that, but that's no good to me. I'd rather disable it.
    36. Re:I have always wondered... by edwdig · · Score: 4, Interesting

      Does Windows gracefully handle the situation where a DLL which is currently in use is replaced, or will I wind up with applications calling two different versions of the DLL depending on when they started?

      The reason Windows updates require reboots is because open files cannot be replaced. So if a DLL is in use at the time of update, it won't actually be installed until you reboot.

      Unix systems, otoh, have decided that the name of a file (the thing the user has control over) is not what actually ids a file, but instead the location on disk is the id. Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.

      I've always wondered how someone could consider the Unix design a good idea. Two different programs can open what they think is the same file, yet get completely different results. And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general).

    37. Re:I have always wondered... by Joebert · · Score: 1

      So, you want to to check with you to make sure you're not doing anything, but you don't want it to talk to you ?

      --
      Wanna fight ? Bend over, stick your head up your ass, and fight for air.
    38. Re:I have always wondered... by ben+there... · · Score: 1

      I want the option for it to just "automatically update" my OS, silently, without rebooting. I'm fine if a systray bubble tells me it needs to reboot, but I don't want any other notifications or tray icons from it, ever. Simple enough. Possible with Pro, I now know. Not possible with Home. It's not configurable enough. I don't have much more to say than that.

    39. Re:I have always wondered... by snoyberg · · Score: 1

      This is a stupid idea though. It saves the administrators some hassle, but if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it?


      That's a nonsensical argument. You could make the same argument for any piece of software at anytime. So it's a useless factor in your analysis of the criticality of the particular issues addressed by any particular patch.

      I think GP's point was that, if M$ delays software patches so that IT departments don't have to hassle with installing every day, the only logical reason is that they assume releasing the patch informs hackers of the flaws. However, it's a two-edged sword since on the other hand delaying patches to know vulnerabilities would have obvious negative effects.

      Note: I only *think* that made sense to anyone but me

      --
      Thank God for evolution.
    40. Re:I have always wondered... by Tanktalus · · Score: 4, Informative

      I still love the ability to replace in-use libraries. The only problems that ever crop up are when you dynamically load another library, and that library disappears (Windows doesn't help here, either), or its API changes (although usually that results in a new library name, so you still get the old one). If you still have a library loaded when it gets deleted, you maintain a filehandle to it so its disk space is not reclaimed or reused. Shut down all applications still loading the old library, and then the disk space gets reclaimed.

      I've updated X.org at least a couple times since the last time I restarted my X server. So I have a bunch of old libraries still sitting on my disk with no way to refer to them (well, there are ways to get them back involving funky lsof/proc tricks, but let's not go there). Nothing will overwrite them. But, when I feel I have the time, I can shut down all my X apps, restart my X server, and free up all that space. But I don't need to take down mysql, apache, or anything not X-based to do so.

      I don't get how anyone could consider this a bad idea. The only times it falls over is when people don't follow convention (change your library number when changing APIs!), or in cases that Windows will fall over, too (dynamically loading libraries that don't exist anymore - although that usually doesn't crash as hopefully most people catch the error return and handle it). Otherwise, it maximises the uptime of your server, so that you only need to restart programs that actually use your library when you want to.

      (PS - thanks for this thread - it answers a question my wife posed - why her windows machine rebooted overnight when she was in the middle of sorting digital photos to send to be printed, and there was no power outage.)

    41. Re:I have always wondered... by Anonymous Coward · · Score: 0

      Well, *nix comes from the large multiuser system angle where uptime is considered very important. Solaris and probably some others require the system to be taken down to single-user mode for major patches which presumably gets around this problem with a little less downtime than rebooting.

    42. Re:I have always wondered... by snoyberg · · Score: 1

      Can someone explain to me why patching the system would break applications? I haven't done any serious programming on Windows, but it seems non-sensical that patching security holes should ever break a properly-coded application to well-defined APIs. And from what I've seen of it, the Win32 API is pretty stable and clear.

      --
      Thank God for evolution.
    43. Re:I have always wondered... by pe1chl · · Score: 2, Interesting

      It can cause problems when abused, but it has come very nice properties.
      For example, you can create a temporary file by opening it (with create option), then deleting its name while keeping the file open.
      Your file will be available as long as you don't close it, and will vanish automatically when you close the file, your program crashes, the system reboots, or whatever.

      No more TEMP directory filling with crap, no need for a program that removes old tmpfiles left when a program crashes, etc.

    44. Re:I have always wondered... by drinkypoo · · Score: 1

      And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general).

      That's because most of them have discovered how to reboot their systems to ensure that there are no long-running processes using a different version of the same library.

      It's good because even if you have an unkillable process zombie'ing around your system, you can still replace a file, reboot, and have things work without having to actually go to single user mode and do things manually. It's important from a remote administration standpoint.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    45. Re:I have always wondered... by SL+Baur · · Score: 1

      I've always wondered how someone could consider the Unix design a good idea. Two different programs can open what they think is the same file, yet get completely different results. And yet some people don't seem to get why this is a really bad thing for shared libraries (or even files in general). It's because you only ever deal with pointers to files (inodes) and the inodes are what are cached when a file is open.

      I consider it a friendly feature when you're debugging vital system libraries. The system stays alive and repairable even if you have just installed a bad libc. You can always find out which instance of a library a running process is linked against anyway. No big deal.
    46. Re:I have always wondered... by Anonymous Coward · · Score: 0

      XP Pro SP2, 2K3, and presumably Vista --- The control panel lets you specify that you don't want it to install until you're ready
      Right, but occasionally it ignores this setting and reboots anyway. Not often, but frequently enough that you can never be entirely sure things won't spontaneously fuck up.

      I had my win2k workstation at work (amongst others) do it sometime between yesterday and this morning, initially we thought it was a brownout but then oh look, there are a couple less critical IE updates pending download and install than there were yesterday, I wonder why ...

      Luckily I'd saved the code etc I was working on, but MS' inability to program something so simple correctly has lost us work in the past.
    47. Re:I have always wondered... by Kijori · · Score: 4, Insightful

      When Microsoft releases a patch for an exploit, it's immediately known that computers are wide open to this attack. Malicious hackers - virus writers and the like included - can reverse engineer the patch to find out what vulnerability is being patched exactly, and know that, since your organization doesn't patch until such-and-such day, you're wide open to attacks. "Exploit Wednesday", the day after patch Tuesday, is a testament to the importance of Microsoft's patches in the development of exploits. Companies can't afford to gear up for patches every day, but can't afford to risk the ramifications of not applying a patch immediately either. Patch Tuesday gets them out of this catch-22.

    48. Re:I have always wondered... by compro01 · · Score: 1

      a properly-coded application

      here's where your thinking diverges from reality.

      --
      upon the advice of my lawyer, i have no sig at this time
    49. Re:I have always wondered... by lgw · · Score: 2, Insightful

      I disable the damn update service. Once a month I hit Microsoft Update, generally on the Wednesday following patch Tuesday. Why is this hard?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    50. Re:I have always wondered... by beckerist · · Score: 1

      That's not always true. The biggest trick is to find the service or application holding that library open. Rebooting is the fastest way to achieve this 99.9% of the time, but in the event of a "media player" or "outlook" update, generally a restart of the application should do it. As you're using Windows, if it's Windows critical (and not simply a module extension or dcom support file) you WILL have to reboot (essentially restart the Windows "application") but you'd be surprised how often it's not mandatory.

      quick related side story: I once had my Win2k3 server backed up with so many "pending updates" that it forced my server to restart. That day (as compared to each day from the month before,) my business dropped by over 80% because of the fact it'd gone down without my knowledge, the downtime was very long, and the fact that when it restarted, it broke my IIS and had to jump to Apache as a backup...

      P.S. I still use Apache...

    51. Re:I have always wondered... by ben+there... · · Score: 2, Informative

      (PS - thanks for this thread - it answers a question my wife posed - why her windows machine rebooted overnight when she was in the middle of sorting digital photos to send to be printed, and there was no power outage.)

      In case you're interested, since starting this thread I did some googling and came up with a solution for both XP Pro and Home.

      how to
      registry entries (works with XP Home as well)

      I guess this has been an issue for about 3 years for people, but it never bugged me bad enough to fix it until I started recording TV on this box. :-)
    52. Re:I have always wondered... by lgw · · Score: 1

      It is always the software designer's fault if the user can't configure the software to meet the user's needs.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    53. Re:I have always wondered... by Tacvek · · Score: 2, Insightful

      My wish is for: Download Automatically. Prompt me when downloaded so i can review what is to be installed. If I install them, and it wants to reboot, but I do not reboot, it may leave a systray icon, but MUST NOT keep popping up that window every 10 minutes asking me to restart. I will generally install the updates ASAP, but I only restart when i want to, or if the system becomes really messed up, or BSOD.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    54. Re:I have always wondered... by lgw · · Score: 1

      The thing is, with Microsoft patches, the exploit comes out *because* the patch comes out. For the most part, you don't need to patch until the patch is released. Once a month is a good comprimise between forcing customers to update too often, and waiting so long that the exploit would show up on its own in the wild.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    55. Re:I have always wondered... by kasperd · · Score: 2, Interesting

      Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.
      The possibility to update without rebooting is great. The problems you mention are very rare. In fact I have only seen that kind of problem once, in the 10 years I have been using Unix systems. And the case where I saw it, it was not even two programs using different versions, but rather one program being started while it was in the middle of being updated causing it to end up with different versions of the different libraries in the package. And even if that had happened every time I upgraded software, it would still be less of a problem than having to reboot every time.

      I've always wondered how someone could consider the Unix design a good idea.
      Considering how well the Unix way works, I wonder how anybody could consider Windows a good idea. In Windows updates requires a reboot far too often. And in Windows you often get errors about files being busy for no good reason. OTOH with Unix you can upgrade a running program and not even notice. The running instance keeps running, any new instance will use the new version. Only problem is, that this usually works so smoothly, that you don't even notice. I recall once noticing, that I had KDE using libraries that had been deleted a month earlier. (Yes, I had in fact not logged out for a month).

      Two different programs can open what they think is the same file, yet get completely different results.
      If you get completely different results, there is a design flaw. We are talking about bug fixes here. The old version have a bug, and if the program triggers that it might crash or even worse produce undefined results (which could be to let in an attacker). The new version does not have the bug. As long as you don't produce the condition, which would trigger the bug, the two versions are supposed to behave exactly the same. And if you do trigger the condition, it is obviously an advantage that the new version behaves as intended. Of course it is not good that the old version doesn't, but the only way to avoid that is by never introducing bugs, which we all know is rarely feasible.
      --

      Do you care about the security of your wireless mouse?
    56. Re:I have always wondered... by lgw · · Score: 1

      Patches break stuff all the time. Patches even break Microsoft's own stuff occasionally, which you can geenrally spot because a patch is released and it's not Patch Tuesday (i.e., it's a patch to a Patch Tuesday patch).

      Generally the problem the is that patch changes some behavior the software counted on. Usually this is undocumented behavior of an API (but then, most behavior of most APIs are undocumented: there are just too mant corner cases). Sometimes a patch actually removes a documented feature of an API because it was hopeles from a security perspective - this is thankfully confined to service pack and ne OS versions (normally).

      --
      Socialism: a lie told by totalitarians and believed by fools.
    57. Re:I have always wondered... by TheSkyIsPurple · · Score: 1

      They're actually not free to test and such... time taken out for this testing is time taken out of other projects and slipping deadlines. Sr. Management typically has tight expectations for timelines and budgets.

      With a predictable schedule, you can schedule resources up front to make sure you're actually addressing things without letting the major projects drop.

      Life in a large company is a different world.

      Plus, once you've announced the patches, you've increased the threat exposure by several orders of magnitude. Without the corporations able to schedule those resources, you increase the likelyhood that they will actually get hit before they have a chance to respond.

    58. Re:I have always wondered... by devilspgd · · Score: 1

      You're not in IT, are you?

      Try managing patches for a hundred thousand systems and you'll understand why less frequency is more important.

      So, why not release them as they make them? Two factors

      1) Your average large IT department is going to schedule the deployment,

      2) Once the patch goes out, all you have to do is look at the patch to see what it changed and you know there was an exploit in the previous version. As a result, looking at patches actually make it easier to find exploits.

      So combining the two, it's more IT friendly to release patches on a fixed schedule which IT departments can plan around, rather then giving the patches to the blackhats right away, knowing the end users won't generally be able to install them until later anyway.

      In general, once a bug is being exploited, the patch goes out ASAP. However, if it is not yet being exploited, there is little harm in delaying a week or two (up to four weeks, the next monthly cycle).

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    59. Re:I have always wondered... by cheater512 · · Score: 1

      You cant understand it because you've never seen it being used.
      Its a bloody fantastic feature.

      I can update half the programs on my computer and I can chat on MSN, surf the web and even play games while its occuring.

      The only catch is that if you update something critical like Xorg then you cant start new applications once its updated because the new library cant talk to the old X server currently running.
      Using already open apps is fine though.

      Its like replacing explorer.exe with a new version while the old version is still running.
      It means that updates are far less disruptive and when you want the new version then you just restart the updated apps.

    60. Re:I have always wondered... by Gordo_1 · · Score: 1

      if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it? Waiting up to an additional month for a patch to come out is really not that big deal when you put it in context: Some patches are plugging holes that have been happily sitting "undiscovered"(?) in the OS code base going back more than 10 years.

      Yes, without a doubt, there is code in Vista that in unchanged since the first version of NT and I suspect snippets of vulnerable Win9x code is still in there too. Scary, huh?
    61. Re:I have always wondered... by devilspgd · · Score: 1

      No -- Most computer users don't leave their computer doing anything productive or useful overnight, and the default avoids the "Hey, you need to reboot now" dialogs that were a constant complaint in the past.

      If you need software to run at all times while your system is on, not just when a user is logged in, install it as a service.

      If you don't want automatic updates to reboot on demand, configure it appropriately.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    62. Re:I have always wondered... by ben+there... · · Score: 2, Informative

      Hey Tacvek, I think my other post might help you too. Specifically, set RebootRelaunchTimeout to 1440 to change that to 24 hours. A couple other options should help too.

    63. Re:I have always wondered... by Yvanhoe · · Score: 1

      By the way, someone knows how to configure windows XP so that it restores the session after it reboots ? I mean relaunching applications, web pages, explorer, Visual Studio, like KDE does when I quit it with applications still running ?

      --
      The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
    64. Re:I have always wondered... by devilspgd · · Score: 1

      Unfortunately, when a patch comes out it's like a giant red arrow saying "Formerly exploitable code located here" -- Anyone who is looking for a vulnerability to exploit who can find it before your average company has time to patch can take advantage of it.

      By scheduling the day patches come out, but not revealing the contents of the patches until that day, you allow IT departments to schedule their patch testing and deployment well in advance.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    65. Re:I have always wondered... by Randseed · · Score: 1

      Shades of Norton. Windows claims to be "easy to use" and all, but the flood of nagware (which includes automatic updates for reasons previously stated) simply make things ridiculous and annoying. I could list plenty of software that does tihs kind of thing, but by far the worst is Norton. Your subscription expires. Norton then insists on waiting until you open an application, then dropping it back to the desktop to display a nag screen telling you to renew. And there is no option for "I don't want to renew your software, so stop bugging me already." Uninstalling it was easy on one machine, but for some reason on the other was a odyssey of epic proportions.

    66. Re:I have always wondered... by devilspgd · · Score: 1

      If an exploit is in the wild, it causes an exception to the patch-Tuesday and the release goes out.

      The problem is that for bugs which are NOT being exploited yet, the patch is a a big flashing red sign saying "Bug here, exploit it before anyone patches it!"

      I've yet to find an IT department that only wants to work on one day a month on patching -- Most are lucky to pull the man power to get patching done once a month.

      Personally, my calendar has my schedule cleared on Patch Tuesday afternoon/evening to test and release the patches for deployment so that workstations can update at the 4am Wednesday update schedule (set by group policies) -- This generally gets the patching done in under a business day, with a minimum of disruption to users, without me needing to be available 24/7 to review and approve patches.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    67. Re:I have always wondered... by devilspgd · · Score: 1

      Not at all -- Until Patch Tuesday started, patches were released as they became available. It was a problem, and so scheduling started.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    68. Re:I have always wondered... by Zonk+(troll) · · Score: 0, Troll

      I haven't done any serious programming on Windows, but it seems non-sensical that patching security holes should ever break a properly-coded application to well-defined APIs. That's the problem. The vast majority of Windows software is, in terms of coding quality, utter and total shit. Especially educational apps, which I've had to suffer with for far too long. Business apps are likely as equally shitty, if not worse.

      This is why I love using Debian (servers) and Ubuntu (desktops). Everything just works. Updates just work, and no reboots are necessary.
      --
      "The Federal Reserve is a fraudulent system."--Lew Rockwell
      End The FED. -
    69. Re:I have always wondered... by devilspgd · · Score: 1

      Generally it's because most apps are not properly coded, do not stick to defined APIs, and no, the Win32 API is not always clear.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    70. Re:I have always wondered... by nschubach · · Score: 1

      Excuse me for being ignorant here (as I didn't know Unix actually did this) but let's say you create a file on a pretty full drive. You open that file, then delete it. Now what happens if another process goes to make a file? Does Unix still hold onto all the allocated disk space and return a disk full error or will it overwrite the part of the disk where your "file" resides?

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    71. Re:I have always wondered... by laffer1 · · Score: 1

      What about disclosure before Microsoft releases a patch. That occasionally happens and then we have to wait for patch tuesday to get the fix. Their current system causes systems to be vulnerable longer for no good reason. Microsoft shifted the analysis of patches from the sys admin to their hands. They don't even give you details about exploits in their security advisories anymore. Its just a vague "there is a vulnerability in product x" kind of thing. I have to search their kb or technet to find out what is wrong with their product. Its a hassle.

      The other problem with patch tuesday is that for your thinking to work every vendor has to release patches on the same day. If IT only does patches once a month, then vulnerabilities in Firefox, Office, and any other business app might go unpatched for a long time. Companies are not out of the catch 22.

    72. Re:I have always wondered... by Anonymous Coward · · Score: 0

      Actually he losses it at:

      And from what I've seen of it, the Win32 API is pretty stable and clear.

    73. Re:I have always wondered... by Kijori · · Score: 1

      Microsoft vary their schedule for some vulnerabilities - I assume there's some sort of cost/benefit going on to decide which ones are worth causing problems to patch quickly. As for the problems with other vendors - that's hardly Microsoft's fault, and at any rate those products tend to be easier to protect than the operating system itself.

      I'm not saying the system's perfect, just that there are good reasons for the existence of patch Tuesday; it's not just a random piece of bureaucracy.

    74. Re:I have always wondered... by pe1chl · · Score: 2, Interesting

      The opened and deleted file still has space allocated and it will not be overwritten by other files. Of course when the disk is full, one cannot add data to the file.

      This is not a "trick". A file in Unix exists independent of its name(s). Each file has 1 name when created, but you can delete the name or add more names. When the number of names becomes zero, the file is deleted as soon as all processes that have it open do close it. As long as it is open, it is a fully functional file that occupies space and can be read and written to.

      There even is a special function in the C library to create a temporary file:

      FILE *tmpfile (void);

      This creates a file, opens it for read+write and immediately deletes it. It is available as a temp file until it is fclose'ed.

      In Unix this is simple to implement. The corresponding function in other systems is tricky and does not work completely correctly.

      When you don't believe it, browse to your TEMP directory in a Windows system, usually C:\Documents and Settings\yourusername\Local Settings\Temp.
      You will find many files with .tmp names or names starting with ~ or $, all meant to be temporary files deleted after use.

    75. Re:I have always wondered... by pe1chl · · Score: 3, Informative

      Unlike the Unix mechanism, where the library is replaced and you would need to voluntary restart your application to make it use the new library, there is no easy way to update a DLL in Windows after it has decided a reboot is required.

      Windows update will try to replace each file, and when it succeeds everything is fine. When not, it will put the file on disk under a different name, add a "rename" operation to a list, and continues with the next file. At the end, when the list is not empty, it requests a reboot. At reboot, the list is processed (the new files renamed over the old ones), and the list emptied.
      But merely stopping an application and closing the file that was in use will not make it rename that file and remove it from the list. You will need to reboot.

    76. Re:I have always wondered... by pe1chl · · Score: 1

      They aren't unable to program simple things correctly, they just have a different agenda.
      Microsoft know very well that creating products that work correctly will not bring them any more sales now, and will cost them sales in the future. So why bother?

    77. Re:I have always wondered... by Tacvek · · Score: 1

      Thanks. That is much better. Not quite perfect, but once a day until I reboot is quite manageable.

      I did not need anything else because the options to download automatically, and prompt are one of the choices in AU's control panel interface.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    78. Re:I have always wondered... by jZnat · · Score: 1

      Well, if the patch changes the ABI, that will definitely break something without a recompile. There's also the chance that the patch just wasn't done right and changes the functionality of some part of the API by accident. And then there's all those uses of undocumented hooks, e.g., with many Microsoft programs as well as anti-virus ones.

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    79. Re:I have always wondered... by Score+Whore · · Score: 1

      Unix doesn't really have the capability of deleting an in use file. You can get rid of the name but anything that had the file open will continue to use the original file. If the application uses dlopen then you can easily enter into a situation where you have mismatches between patched library X and unpatched library Y.

      I'm a unix admin by trade. Just wanted to get that out there before I said my next bit....

      I'd be very impressed by any unix system that allows you to patch libc or the run-time linker without requiring a reboot to get the patch active in all processes.

    80. Re:I have always wondered... by Score+Whore · · Score: 0

      I still love the ability to replace in-use libraries.


      You can't replace in use libraries. You can only choose to run multiple versions of the same libraries. And it can cause problems. Private interfaces can change and next thing you know you've randomly shuffled line items between thousands of invoices.

      Otherwise, it maximises the uptime of your server, so that you only need to restart programs that actually use your library when you want to.


      Don't take this wrong, but I'd never hire you as my server admin. The uptime of your server is irrelevant. Patch when it suits your needs, follow the proper procedure. Don't sit around playing thought experiments on your production systems.

      How do you know you haven't introduced a significant probability of data corruption with your X.org patches? You have active processes using old libraries and new processes using new libraries. Unless you personally have audited every line of code changed and understand the entirety of the change and how it interacts with the rest of the system, it's impossible to know that your system is not silently eating your data.
    81. Re:I have always wondered... by Score+Whore · · Score: 1

      I understand what he said, I just don't think it really makes any sense. Any piece of software can have an exploit of limited publicity (eg. known only to black hats.) In fact you should be assuming that every piece of software you have does have bugs. And acting accordingly.

      Microsoft's process serves multiple purposes. First, it lets them have a process in place for developing patches, regression testing, packages, getting sign-offs from management, etc. all under a known schedule, process and time table. Secondly it allows people to know when to expect to receive patches. So your own internal processes can accommodate this.

      Microsoft has released patches for issues that are considered high risk outside of their regular schedules. So it's not like you're going to be stuck waiting when there is a major and significant issue.

      Another consideration is that end users have already planned their security environments around the idea that all software has bugs and vulnerabilities. A remote exploit in SQL server doesn't mean that the system is suddenly owned by every script kiddie on the internet. Anyone running SQL server is going to have deployed it under some controls. Their vulnerability will be limited. Getting it patched will be a priority, but not the most important thing associated with that particular deployed system. The is to say, day to day operations will continue until IT has scheduled time to apply the patch. As such, the exact delivery date of the patch is usually not the most important thing in the world, Friday... Tuesday... same difference.

    82. Re:I have always wondered... by Score+Whore · · Score: 1

      FILE *tmpfile (void);

      This creates a file, opens it for read+write and immediately deletes it. It is available as a temp file until it is fclose'ed.


      Not according to my man pages (which could be wrong):

      The tmpfile() function generates a unique temporary filename. The temporary file is then opened in binary read/write (w+b) mode. The file will be automatically deleted when it is closed or the program terminates normally.


      Fundamentally it's a bad idea anyway. As programmers we need to stop thinking we're clever and start thinking about operational issues. If you've got a bunch of applications on your system all consuming invisible data, how can you choose which one to kill to resolve an out of space situation? Yes, I know there are ways to figure it out by inspecting private kernel data structures with tools like lsof, or waddling around in /proc, or even just loading up your favorite debugger. But get real.
    83. Re:I have always wondered... by Score+Whore · · Score: 1

      Why would you want to do that? Seriously. Who wants a half patched system?

      BTW. You can do this with windows too. It applies the patches, anything that can't be replaced is scheduled to be replaced at next reboot. Then it tells you that you need to reboot and gives you the option of telling it again in a few minutes that you want to reboot later.

      Effectively the exact same thing. Half patched.

    84. Re:I have always wondered... by Anonymous Coward · · Score: 0

      Except that in unix you don't have to reboot the computer, just restart the affected applications. Rebooting is a lot more of a pain in the ass.

    85. Re:I have always wondered... by edwdig · · Score: 1

      It's good because even if you have an unkillable process zombie'ing around your system, you can still replace a file, reboot, and have things work without having to actually go to single user mode and do things manually. It's important from a remote administration standpoint.

      If you're going to reboot, then it loses all advantages you're trying to claim. Do it like Windows does - just have the system automatically make replace the files extremely early on in the boot process. Do it before the distinction between single / multiple user mode.

    86. Re:I have always wondered... by grasshopper-1975 · · Score: 1

      So, the biggest reason that I can remember for the creation of patch Tuesday's was that system administrators, and other computer savvy people, complained that they had to patch a system what seemed like every day. Microsoft used to release patches when they finished them, but changed their policy to only provide patches once a month. While I am a system admin, and like only having patches once a month, I also like the other side of the coin that can have me patch my systems when the patch is ready if I so choose to do so. For non-system admins, you can use the control panel applet to set the date\time that you want your patches to install(Auto with set date\time, download and prompt me, just prompt and don't download). You can also choose to not apply the patches, and create a scheduled task using a script that will apply the updates, and then reboot. We use a script on all of our servers, and apply patches as part of the regularly scheduled reboot of the server.

      --
      Questions are a burden to others; answers a prison for oneself.
    87. Re:I have always wondered... by edwdig · · Score: 1

      It's because you only ever deal with pointers to files (inodes) and the inodes are what are cached when a file is open.

      You don't deal with inodes directly. You deal with filenames, which internally get mapped to inodes. There's no reason the user / developer should ever have to know what an inode is. For whatever reason, the Unix developers decided to let it show through.

      I consider it a friendly feature when you're debugging vital system libraries. The system stays alive and repairable even if you have just installed a bad libc.

      Last time I did that (probably back in the 90's), any process already running worked, but I couldn't start any new processes. Remember, cp, rm, and mv are usually just programs in /bin, so if core libraries are hosed, you can't use them. I have to give credit to MS for being smart enough to make the corresponding commands built into command.com / cmd.exe.

      You can always find out which instance of a library a running process is linked against anyway. No big deal.

      You shouldn't ever have to do that. Shared code should always be shared identically between everything using it.

    88. Re:I have always wondered... by Martin+Blank · · Score: 1

      Indeed, the turnaround time from patch release to first exploit is now well under 24 hours for many of them, and exploit code is often out the very same afternoon. This makes it that much more difficult to safeguard the enterprise.

      --
      You can never go home again... but I guess you can shop there.
    89. Re:I have always wondered... by edwdig · · Score: 1

      I don't get how anyone could consider this a bad idea. The only times it falls over is when people don't follow convention (change your library number when changing APIs!)

      The problem isn't when APIs change, because as you said, the number should change. The problem is when the implementation of the API changes.

      Anything internal to the library can change at any time, regardless of the library version number. This isn't a problem on self contained code, but leads to potential problems with programs that interact with each other. Say you have a database library that supports multiple processes accessing the same file. To implement this, the DB library has a series of locks on the file. Some realizes a potential locking problem, and reorders the calls to grab the locks to solve it. Now, you have a program running accessing the DB at the time you do the update. You now start another instance of the program. You have two instances running with different library versions. They're now performing different locking logic. You've just drastically increased the odds of data corruption and / or deadlocks.

    90. Re:I have always wondered... by edwdig · · Score: 1

      You cant understand it because you've never seen it being used.

      Quite the contrary. I can't understand it because I've seen where it fails, and I've done enough system programming to be rather familiar with how horrible an idea it can be.

      The only catch is that if you update something critical like Xorg then you cant start new applications once its updated because the new library cant talk to the old X server currently running.

      That's exactly where the problems come in. Any kind of interprocess communication becomes a total crapshoot. Even though process X and process Y are both using /usr/lib/libfoox.y.so, you have no guarentee that the two libraries can talk to each other. Remember, the version number in an so file refers to the external API - it says nothing about the implementation of that API.

    91. Re:I have always wondered... by grasshopper-1975 · · Score: 1

      Just to throw it in, here is my patching strategy. I am lucky enough to have a fairly good base of Development and QA devices. I currently use 3 vehicles to deliver a patch. 1.)WSUS for managing patch downloads, approvals, etc... 2.)Group Policy for what, where and when. 3.)Scheduled tasks with a javascript to run windows update. The schedule: Patch Tuesday - Patches applied automatically to IT Infrastructure and Help Desk staff (controlled via Group policy) Thursday after Patch Tuesday - Patches released to the rest of IT (Developers, QA department, and our Information Protection Group) Monday after Patch Tuesday - Patches approved for Dev and QA servers. (again, controlled via Group policy, but I manually check the boxes) 2nd Monday after Patch Tuesday - Patches are released to a test bed of PC's in the business. These are usually the SME's of the department. 2nd Thursday after Patch Tuesday - Patches are released to the rest of the business (controlled via group policy to apply at 11:45 AM for the corp office, most users have no issues rebooting before going to lunch, and for our other areas at times that are end of shift) When the next version of SMS comes out, we will probably change the deployment method to a nightly push, and wake up the PC's to do it. 2nd Thursday after Patch Tuesday - Patches are also approved for installation on Production servers. We use a javascript to install the patches as part of their regular maintenance window. Those windows may be daily, weekly, or monthly depending on the server function, but ALL windows server have a LOB agreed upon (in writing) maintenance window or I will not install the server. That is basically our patch schedule and how we deploy. I can say that we are usually in the 95% patched range on client PC's within 30 days of release, and 99% patched range on servers within 30 days. Hopefully someone will find our method as usable for themselves. I can say that if M$ did decide to change to a daily released patch schedule, then I would have to consider setting up additional test groups, but the

      --
      Questions are a burden to others; answers a prison for oneself.
    92. Re:I have always wondered... by SL+Baur · · Score: 1

      Last time I did that (probably back in the 90's), any process already running worked, but I couldn't start any new processes. Remember, cp, rm, and mv are usually just programs in /bin, so if core libraries are hosed, you can't use them. I have to give credit to MS for being smart enough to make the corresponding commands built into command.com / cmd.exe. Of course, that's why you need cp, rm, mv etc. statically linked, or you should have sash (statically linked, of course) installed. (Busybox may be the modern equivalent of sash, but I've never investigated it).

      Smart and command.com are oxymorons based on the code I audited - a delightful mix of CPM/86 and dumbed down Xenix with lots of really stupid bugs and very useful but hidden features. Maybe it got smarter.
    93. Re:I have always wondered... by edwdig · · Score: 1

      Of course, that's why you need cp, rm, mv etc. statically linked, or you should have sash (statically linked, of course) installed. (Busybox may be the modern equivalent of sash, but I've never investigated it).

      Good advice, but a lot of distros don't follow it. Just checked my Fedora box - /bin/cp is linked against 8 shared libraries.

      command.com almost certainly is horribly written, but that doesn't mean that it wasn't a really good idea for it to have the core commands built in.

    94. Re:I have always wondered... by El_Oscuro · · Score: 1

      I have found it quite easy to clobber an in-use file in Windows (the hard way). Just do it remotely using a NT share. Try:

      copy somefile.dll \\remote_server\c$\windows\system32

      Of course, this was NT 4.0. It might be fixed now.

      --
      "Be grateful for what you have. You may never know when you may lose it."
    95. Re:I have always wondered... by cheater512 · · Score: 1

      Actually they will talk fine as long as they were both opened at the same time (either both before or both after the upgrade).

      Its usually not a hassle either to restart the updated apps.

    96. Re:I have always wondered... by edwdig · · Score: 1

      Actually they will talk fine as long as they were both opened at the same time (either both before or both after the upgrade).

      That's exactly my point. The Unix way leaves a window where things might not work and just relies on the fact that most of the time there won't be a problem.

      You aren't forced to reboot because you're giving up the guarantee that everything is correct.

    97. Re:I have always wondered... by eleveneleven · · Score: 1

      i couldn't agree more with this

      --
      C7 C4 25 8A 11 BB 0D 40 8F 4E 4E 47 CA F0 BE 5B
    98. Re:I have always wondered... by geekboybt · · Score: 1

      No need to open up group policy and sift through it. My computer > Properties > Automatic Updates.

    99. Re:I have always wondered... by pe1chl · · Score: 1

      It is too common in IT land to call someone else's good solution to a problem "a fundamentally bad idea".
      Apparently all solutions have advantages and disadvantages. When you spend your day looking at systems with full disks and having to decide what programs to kill to resolve that, you might have a point. But for me, that does not happen too often.

    100. Re:I have always wondered... by Tim+C · · Score: 1

      Because their large corporate customers demanded it, as it's much easier to schedule testing and roll out of patches if they come out on a regular schedule than if they're drip-fed as and when they're actually ready. Don't forget that some teams are managing literally thousands of desktops.

      You can't blame MS for this one, they actually listened to their customers and gave them what they wanted.

    101. Re:I have always wondered... by Architect_sasyr · · Score: 1

      I would like to take this moment to make note of something the man who got me into FreeBSD once said (probably others have too):

      You have a server that requires rebooting. REBOOT THE FSCKING THING. No point mucking around if a reboot will solve your problem.

      I'm all for uptime, as far as I'm concerned it indicates that I've got a rock solid system able to support 100+ users at any given time. OTOH: there's a memory leak in some software written to help administator my network. I'm not there at night so rebooting it daily resolves that issue (I didn't write it and haven't the time to fix it). Do I care for the crappy uptime? No. My network runs as perfectly as I can get it to because I'm willing to cycle the power on a system when its necessary.

      IMHO the biggest advantage of the Unix file system is being able to roll all my updates out AND THEN force my users to restart their program. Means that I've only got a few seconds down time rather than waiting for a lot longer as they all log out and have their files patched.

      My $0.02 AU

      --
      Me failed English...
      FreeBSD over Linux. If my comments seem odd, this may explain...
    102. Re:I have always wondered... by Raideen · · Score: 1

      You can still plan ahead. i.e. There's no reason why you can't have your own patch Tuesday. The only difference that I see is your boss' view of culpability.

      "Why wasn't that security patch for vulnerability X applied in time before we got hit?"

      A. Because we were waiting for our monthly test cycle so that we can test a lot of patches at once instead of one at a time at various days of the month.
      B. Because Microsoft didn't release it until patch Tuesday, which [was after we got hit|didn't give us enough time to test the patches before getting hit on Wednesday].

      I believe that the primary reasons for having a patch Tuesday are:
      -simplified tracking of patches (just look for the releases from that day)
      -Microsoft doesn't have to make 5 or more announcements per month
      -your desktop PCs only need to reboot once a month (instead of once every time a patch with a required reboot is released)
      -OCD sysadmins aren't compelled to install each individual patch on the day of release ;-) (I actually don't know any sysadmins that would do this, but some customers that do their own maintenance do.)

    103. Re:I have always wondered... by Raideen · · Score: 1

      You always wondered? You must be fairly new to IT. Not everyone on /. is in IT.
    104. Re:I have always wondered... by todslash · · Score: 1

      Fundamentally it's a bad idea anyway. As programmers we need to stop thinking we're clever and start thinking about operational issues. If you've got a bunch of applications on your system all consuming invisible data, how can you choose which one to kill to resolve an out of space situation? Yes, I know there are ways to figure it out by inspecting private kernel data structures with tools like lsof, or waddling around in /proc, or even just loading up your favorite debugger. But get real.

      I agree it's not ideal but sometimes it might be handy.

      I used to work on a software package which deletes it's temporary files. On occasion it can use many gigabytes of scratch files and was originally developed back in the eighties when disk space was at a premium.

      The most common cause of the software filling up a disk was the user being too ambitious in their input and naively starting a job which would need terabytes of disk space (and decades of CPU time). It would happily churn away until the disk filled up and then fall over. As this was normally in the middle of the night it was much better for the unlinked files to disappear when the job crashed rather than everyone arriving in the morning and not be able to do anything until either the sysadmin or user did something about it.

      I'm guessing that all the various ways the code could exit, crash or be killed could have been trapped and the scratch files dealt with but this was deemed the simplest and most surefire way to make sure they didn't hang around.

      Nowadays an intelligent queueing system can have separate scratch directories for each job and clean up afterwards but you can't always rely on that.

    105. Re:I have always wondered... by Steendor · · Score: 1

      Though I'm not the official sysadmin at my place of business, I spend more time than he does managing the updates on our domain, which consists entirely of Windows machines. When critical updates are available, they're downloaded immediately. For people who turn their computers off, the updates are installed during shutdown. For people who log off and leave their computers on, the updates are installed automatically overnight, and the computer is automatically rebooted if the updates call for it. For people who also stay logged on, the computer is not automatically rebooted; instead it pops up a dialog [that won't go away] insisting they need to save their work and reboot. At home, I always use my admin account (I know, shame on me), and every time updates are available, it tells me. I install them when I'm ready, and reboot if necessary. More than one friend of mine also use the "download but don't install" setting, and then leave their computer running for weeks or months without ever installing the updates. Funny thing, they've never automatically rebooted because of it...

      In the context of automatic updates, I've never had a problem. I adjust the settings the way I want them, and it behaves. I do occasionally find that a computer has automatically rebooted itself while a user was logged in. Every time that happened, either there was a blue screen error, or a power outage, or the cleaning lady hit the power button, (or the power supply failed - which happens a lot around here for some unknown reason - but then the computer's still off the next morning). Sometimes, it coincides with an update release and some updates - the ones that didn't require a reboot - managed to be installed.

      If automatic updates is causing you heartache, then disable the feature and get your updates manually from update.microsoft.com. Since they're released on a schedule, it's not as if you don't know when new updates are available.

    106. Re:I have always wondered... by Thundersnatch · · Score: 1

      Yes, without a doubt, there is code in Vista that in unchanged since the first version of NT and I suspect snippets of vulnerable Win9x code is still in there too. Scary, huh?

      Without a doubt, there are code snippets on Unix, Linux and BSD systems that date back 30 years or more. How long has telnet been around? Sendmail? BIND? X? Assuming all that really, really old code is free from vulnerabilites simply because it is old is absolute folly.

    107. Re:I have always wondered... by LurkerXXX · · Score: 1

      Ok, 'new to windows' then. Is that better? Anyone who bothered to patch their machines regularly knew of this change. Before ~5 years ago, patches would come out individually. Of course, most folks who aren't 'into' IT in some fashion didn't bother to patch anyhow.

    108. Re:I have always wondered... by Anonymous Coward · · Score: 0

      the problem (and the point that so many of you seem to miss) is that if it doesn't reboot, then you're not really patched.

    109. Re:I have always wondered... by Anonymous Coward · · Score: 0

      No more TEMP directory filling with crap, no need for a program that removes old tmpfiles left when a program crashes, etc. Actually Windows has a mechanism for this too: there's a FLAG_FILE_DELETE_ON_CLOSE option you can pass into CreateFile(). If only people used the APIs correctly.
    110. Re:I have always wondered... by Walter+Carver · · Score: 1

      Even if Microsoft released pathces immediatelly, the IT departments could choose to patch whenever the feel like it.

    111. Re:I have always wondered... by Tacvek · · Score: 1

      I am aware of that. But in many cases you are partially patched, depending on the specifics. In any case, I am not concerned about the patch not taking affect for the first few days before I reboot.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  2. Otherwise known as... by ivan256 · · Score: 0, Troll

    Patch Tuesday - AKA: The day before the zero-day exploits are released.

    1. Re:Otherwise known as... by drinkypoo · · Score: 2, Informative

      Patch Tuesday - AKA: The day before the zero-day exploits are released.

      That's not true. They're released before the patches come out. Microsoft provides vulnerability information through a webpage now.

      All the more reason to ditch the patch tuesday, and just release patches when they are ready. As I have repeatedly pointed out otherwhere recently, if you want to install the patches monthly, you can wait for some arbitrary day of the month, and then install the patches.

      This is how Microsoft schedules patch releases, so doing this would preserve the existing behavior for those seriously confused people who prefer it. Waiting to release patches is bad for everyone, except the people profiting from exploits.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Otherwise known as... by toleraen · · Score: 1

      I'm guessing the reason they wait for one day is for their own internal QA process (hear me out!). It can be much easier to test and verify 10 patches at once, instead of testing one at a time. I would assume (hope) that they build systems with the new patches, and stress the systems for a certain amount of time to make sure their compliant with their own internal standards. Testing them all separately as they come out would require a lot more resources, and could end up taking even longer.

      Obviously take that with a grain of salt, since we've all seen the 'emergency patch after patch day' deal. Just my take.

    3. Re:Otherwise known as... by Findlerman · · Score: 1

      "the day before the zero-day exploits are released"
      ...that word. You keep using it. I do no think it means what you think it means.

      http://en.wikipedia.org/wiki/Zero_day

    4. Re:Otherwise known as... by Anonymous Coward · · Score: 0

      A zero-day exploit is one that has not been patched yet. That's why they are called zero day, because there was no time prior to the exploit to avoid it (except maybe obvious things like closing ports and stuff).

    5. Re:Otherwise known as... by drinkypoo · · Score: 0, Troll

      Obviously take that with a grain of salt, since we've all seen the 'emergency patch after patch day' deal. Just my take.

      I've had THIS conversation repeatedly, too. My argument against is the same as yours - clearly, the QA is not effective. We've seen that time and time again. They don't even adequately test service packs!

      It's a great idea, but the evidence just doesn't support it. I'm not saying they're not doing QA, just that it's not what's stopping the timely releases. Besides, one of two things must be true; either the tests complete at different times, which means that some patches could be released earlier, or that some of the tests are being terminated before they complete, to make them all terminate on time for patch tuesday. I would of course suspect the former before the latter.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Otherwise known as... by Anonymous Coward · · Score: 0

      It was stated a long time ago that it was to help IT have a more managed patch day.

      Each patch is tested thoroughly, but a lot of things happen out in the wild such as odd buggy printer drivers, as noted by this post by a Microsoft developer: http://blogs.msdn.com/oldnewthing/archive/2007/05/ 04/2402028.aspx

    7. Re:Otherwise known as... by drinkypoo · · Score: 1

      Let's be clear as to what that particular Microsoft developer did. Instead of writing a process that throws an exception any time the ShellEx does anything it doesn't expect, it tests for the ShellEx to do something unacceptable that it does expect. Any software designed from this mindset is automatically going to be less stable and reliable, it's not going to catch as many errors, and it's going to cause you problems. This guy made an amateur mistake in spite of being an experienced programmer. I would bet some good money that the Microsoft test suite for this product was based on testing for a limited set of known bad behaviors.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:Otherwise known as... by toadlife · · Score: 1

      No. A zero day exploit is an exploit that the general public does not know about at all.

      --
      I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
    9. Re:Otherwise known as... by devilspgd · · Score: 1

      clearly, the QA is not effective

      You've never done QA for a large project, have you?
      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    10. Re:Otherwise known as... by jZnat · · Score: 1

      I believe he's referring to new exploits that weren't fixed by patch tuesday, so that gives the black hats a full month of exploiting fully patched Windows boxen.

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    11. Re:Otherwise known as... by ivan256 · · Score: 1

      So... You agree with me, and the joke went over your head? Excellent.

    12. Re:Otherwise known as... by ivan256 · · Score: 1

      Read your own link. A Zero-day exploit is a exploit that is available on the same day as, or before the vulnerability is made public. If you wait until post-patch wednesday to announce the vulnerability you discovered and release an exploit, your exploit will probably be zero-day for quite a while.

  3. Riiight... by Starteck81 · · Score: 0

    That's like saying there are too many cracks in a large damn so you might as well give up on trying to patch them.

    --
    "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed H
    1. Re:Riiight... by compro01 · · Score: 1

      That's like saying there are too many cracks in a large damn so you might as well give up on trying to patch them.

      more like patch them as they're found rather than wait until "dam repair tuesday"

      --
      upon the advice of my lawyer, i have no sig at this time
    2. Re:Riiight... by devilspgd · · Score: 1

      To continue a stupid analogy, keep in mind that the dam needs to shut down to be patched. Rather then saying to the people relying on the water and electricity from that dam "We're shutting down each Tuesday for a few minutes", you're suggesting saying "We're shutting down randomly all the time. Enjoy"

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
  4. Volume of patches won't get better by Dynedain · · Score: 2, Interesting

    "The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time."
    "

    So the sheer volume of daily patches would make this better?

    Now, MS should take a clue from Apple and have a lot more "rollup" packages than they currently do.
    --
    I'm out of my mind right now, but feel free to leave a message.....
    1. Re:Volume of patches won't get better by aichpvee · · Score: 0, Troll

      Also wouldn't hurt to take a lesson from apple and scrap their operating system and start over with a *nix.

      --
      The Farewell Tour II
    2. Re:Volume of patches won't get better by gad_zuki! · · Score: 3, Insightful

      Patch day was started because administrators didnt want random patches being pushed out at random times. Its supposed to help the process by giving people a schedule, especially for people who arent using SUS.

      The real question is when are they going to patch the patch system. The 100% CPU svchost bug is killing me and KB916089 (and its predecessor) doesnt do squat.

    3. Re:Volume of patches won't get better by Intron · · Score: 2, Funny

      To reduce the problems caused by the volume of daily patches, they could save them until a particular time and refer to that as "patch minute". I propose that they make this 5:35 pm in each local timezone to catch the IT staff who are trying to sneak out and have a home life.

      --
      Intron: the portion of DNA which expresses nothing useful.
    4. Re:Volume of patches won't get better by jimstapleton · · Score: 1

      I agree, on both counts

      The author of the article is an idiot or never andministrated massively patched software if he thinks that more frequent and releases would make things easier.

      If there is any testing, the majority of it would be redundant between patch stuff, to make sure critical things weren't inadvertantly broken. Say that takes 1 day per patch set, now if there are 10 patch sets in a month instead of 1, you just had 10 days spent.

      That being said, while a release-when-done actually make an administrators job harder to keep a system up-to-date with the current patches, it would improve the security of the OS.

      Ideally, I'd say something between that and what we have now would be good, once a week patches - not quite frequent/randome dates, but the time between a fix being available and a release would not exceed a week, instead of potentially being up to a month.

      --
      34486853790
      Connection too slow for X forwarding? Try "ssh -CX user@host"
    5. Re:Volume of patches won't get better by Chosen+Reject · · Score: 1

      Oh thank you. My wife's laptop has been going crazy with svchost using up insane amounts of CPU and memory. I seriously thought it was virus for a long time until I ran it through several anti-virus programs, then I noticed it went craziest in conjunction with Yahoo's IM client. But even after removing that it still was weird. I didn't know what else to think. I hadn't thought that it would be a bug (I don't know why not, it's MS after all?). At least now I know who to blame.

      --
      Stop Global Warming!
      Just say no to irreversible processes!
    6. Re:Volume of patches won't get better by suv4x4 · · Score: 1

      Oh thank you. My wife's laptop has been going crazy with svchost using up insane amounts of CPU and memory. I seriously thought it was virus for a long time until I ran it through several anti-virus programs, then I noticed it went craziest in conjunction with Yahoo's IM client.

      Actually, SVCHOST at 100% doesn't necessarily mean it's the bug this KB article is talking about. SVCHOST, as the name suggests, is a host process for services. Any service that it hosts could cause the CPU utilization.

      You need to download proper tools (such as Process Explorer by SysInternals /owned by Microsoft/ - freeware tool) and see which exactly service causes the problem.

      It *could* be a virus, or a poorly written service, or a service in conflict with some hardware/software piece on your system.

    7. Re:Volume of patches won't get better by gad_zuki! · · Score: 1

      No, its automatic updates, thats the process in svchosts thats causing this. disabling the automatic updates service fixes this bug, but thats just a temporary workaround. google around for this, you'll see its happening everywhere. supposedly MS has 'top people' on it.

    8. Re:Volume of patches won't get better by bubblegoose · · Score: 1

      We have found the you should not acknowledge any svchost errors, just move the error message aside. Run 927891 again. Shut down. When it comes back up run sfc.exe /scannow. Reboot and then you should be able to run MS update.

      --
      I hope that someday we will be able to put away our fears and prejudices and just laugh at people. - Jack Handey
    9. Re:Volume of patches won't get better by lgw · · Score: 1

      Also wouldn't hurt to take a lesson from apple and scrap their operating system and start over with a *nix. They did. It was called Windows NT. One might argue that they started over with "a VMS", but it was Posix compatible in any case.
      --
      Socialism: a lie told by totalitarians and believed by fools.
    10. Re:Volume of patches won't get better by devilspgd · · Score: 1

      Ick, rollup patches are the worst of both worlds -- It means you hold patches until a specific day, *and* you hide the number of exploits which are being patched.

      Worse, if a single patch does cause problems and needs to be withheld by an IT department, it prevents the IT department from releasing the other patches in the rollup.

      Luckily Apple doesn't have a large enough market share for this to matter on a global scale.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    11. Re:Volume of patches won't get better by grolschie · · Score: 1

      Oh crap. I was finally going to get around to migrating from SUS to WSUS today. Should I not do this?

    12. Re:Volume of patches won't get better by SNR+monkey · · Score: 1

      Some of the systems where I work had this problem a few weeks ago. I found this thread on google groups and everything worked fine after that. Aside from that, our only luck was disabling audtomatic updates entirely (don't try going to windows update manually because it'll still cause the problem). As another poster mentioned, some people have problems with the windows update checking for office upgrades too, and if you disable that and only check for OS updates, it 'solves' the problem.
      Best of luck to you, this bad patch is especially annoying.

    13. Re:Volume of patches won't get better by Dynedain · · Score: 1

      If patches have been out for 6 months or a year, there's no reason why there shouldn't be a rollup patch that includes them.

      Rollup patches can be optional, and I'm not suggesting them as a replacement to individual patches. But when you setup a new machine, it's a real pain to run through all the patches if you haven't slipstreamed them in. Or if you have to support a machine that hasn't been updated in quite a while, same problem...

      --
      I'm out of my mind right now, but feel free to leave a message.....
    14. Re:Volume of patches won't get better by liam193 · · Score: 1

      In this case it is the automatic updates.

      More specifically, it's the step in the automatic update process where it identifies what should be downloaded. Once the list is compiled, it seems to do fine with downloading and installing. This means that if you machine is set on any of the options except no updates, it may possibly lock up for anywhere from 10-30 minutes. This just started happening for a number of machines that I use. I've seen it on at more than 5 XP Pro machines and at least one XP Home machine. The first machine it happened on, I thought was a virus. I hard rebooted the machine multiple times (and 30 seconds after login svchost.exe would kick off again) before I found out someone else was having an issue and it resolved itself after about 15 minutes. During the problem, you can't even get the task manager to come up because the system gives everything to svchost.exe for the check. If you have the task manager up before it kicks off, you can actually see that it does in fact take the whole system for that process.

      Interestingly enough, I never saw this behavior until this last round of patches.

    15. Re:Volume of patches won't get better by devilspgd · · Score: 1

      How is it a pain? They're all in the list, all set to patch by default, all you have to do is hit the "Install Updates" button.

      The process is the same for one big patch or a dozen little ones.

      --
      Give a man a fish, he'll eat for a day, but teach a man to phish...
    16. Re:Volume of patches won't get better by suv4x4 · · Score: 1

      During the problem, you can't even get the task manager to come up because the system gives everything to svchost.exe for the check. If you have the task manager up before it kicks off, you can actually see that it does in fact take the whole system for that process.

      You know, I wondered why would Windows allow a process to lock up the entire OS. The process in question isn't in real-time priority, it's not even in high priority.

      We have preemptive multitasking... so what on Earth. I don't remember such experiences on Ubuntu, and I'm not bashing Windows, but I'm genuinely interested why Windows sometimes has difficulties handling priorities with stuck processes.

    17. Re:Volume of patches won't get better by Allador · · Score: 1
  5. How does this help by Zadaz · · Score: 1

    How does the existence (or not) of Patch Tuesday change the number of patches deployed on your network?

    And why are you relying on MS to keep your network secure?

    1. Re:How does this help by Anonymous Coward · · Score: 0

      And why are you relying on MS to keep your network secure?

      Small businesses don't have the money to pay a network security expert.

  6. SUS by u-bend · · Score: 2, Insightful

    I'm not a fan of MS, nor am I a network administrator, but if you're running a network large enough for patching to be a big problem, shouldn't you have a PDC or BDC or something like that that runs SUS? Then you can choose which patches get installed to clients, and when, right? Probably an oversimplification, but it helped in management of our M$ boxes at a previous job.

    --
    u-bend
    1. Re:SUS by sanityfeactory · · Score: 0

      Actually its not much of a simplification. SUS can deploy patches across M$ networks with little to no impact. The biggest problem most sadmins find in large enterprises are legacy systems that are only patched periodically (once a quarter). Microsoft exposes patches ahead of their automated install date (via Auto-Update) too. So, if you're a good sadmin you're probably waiting for the out-of-cycle release of said fix so that you can smoke it on your enterprise *long before* "patch Tuesday." Its actually kind of funny to read all this belly aching. Cry me a river, how hard can it really be? Back in the day, we had ~10,000 servers to update and used VBS and batch files to make most of that happen. If you're still deploying .msi by remoting to each and every server in your stable your making it difficult on yourself.

    2. Re:SUS by LurkerXXX · · Score: 1

      Umm, those large corporate customers that wanted patch Tuesday, so they can test their huge suite of in-house-developed apps against all the patches at once *DO* have machines running WSUS.

      Testing is a huge issue. Rolling out the patches isn't. If the testing takes 2 weeks, and MS releases a new patch every other day for 10 days, they don't want to suddenly have 10-weeks worth of testing in the pipeline. They want to do it all at once.

      Reality check:

      Often hackers do come out with new novel exploits for unknown (to the public) bugs. Most often these days, when a new bug is found either by MS or a responsible security hacker (who tells MS about it and gives them a reasonable amount of time to create/test a patch before releasing details to the public), the hackers leap on the new patch, do a diff on the system between a newly patched and unpatched system, and reverse-engineer a bug to expoit unpatched machines. They then release the exploit to that vulnerablity, and make bot-nets out of unpatched boxes.

      By releasing patches as each becomes available, you create that huge ugly pipeline for the corporate folks to deal with, so if they want to wait on testing until a few patches accumulate, some of those exploits have now been released way way before testing gets done (or even started), and their machines get nailed. By releasing them monthly, you narrow down that time-window of exploitable machines to two-weeks or less for that company.

      And if an in-the-wild exploit is found for something, MS does often release an out-of-cycle patch, so that folks can patch as soon as the patch is available.

      In short, having WSUS available is NOT the issue.

    3. Re:SUS by TENTH+SHOW+JAM · · Score: 2, Informative

      Probably an oversimplification,

      It isn't a matter of deploying patches. Deployment of software is one of the main functions of a large network. It's a matter of choosing the patches.

      If you have 200 core software packages on your big network and a huge number of one offs, then the patch must play nicely with 200 packages. Does it? Lets check. (test against app 1, tick, test against app 2 ...) OK now deploy and hope it does not break too many one offs.

      --
      A sig is placed here
      To display how futile
      English Haiku is
  7. The Real Reason for Patch Day by Gary+W.+Longsine · · Score: 3, Insightful

    Dennis Fisher fails to grok. Patch Day was created because Microsoft was getting hammered by the poor press which resulted from releasing many patches in one month. Patch Day, as much as it sucks, is probably here to stay.

    --
    If you mod me down, I shall become more powerful than you could possibly imagine.
    1. Re:The Real Reason for Patch Day by Trailrunner7 · · Score: 1

      That's not true. MS gets killed no matter whether they release 15 patches in one day or 15 over the course of a month. The question is when they release them in relation to when the vuln is disclosed. Waiting 3 weeks makes no sense.

    2. Re:The Real Reason for Patch Day by sharkey · · Score: 2, Funny

      Dennis Fisher fails to grok.

      True. Patch Tuesday will arrive when waiting is filled.

      --

      --
      "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
  8. Not MS' problem by l4m3z0r · · Score: 1

    Sounds to me like your IT staff doesn't know how to do their job effectively. Many companies and schools with hundreds or thousands of computers are able to stay patched. It might be more prudent to fire your current IT staff and hire some people that are capable enough to apply patches quickly and remotely without trouble.

    1. Re:Not MS' problem by sqlrob · · Score: 1

      The problem isn't application (or shouldn't be). The problem is testing custom business critical apps, or other third party apps that may break.

    2. Re:Not MS' problem by danlor · · Score: 2, Insightful

      Sounds to me like you are the problem. That's a heinous comment.

      Patching is dangerous. It is not for the foolhardy, or ignorant. Your IT department is there to protect you from the "just do it" mentality. Trust them, and when they wine about problems in the process, take heed.

      Our systems have been taken down twice this year due to bad patches from good old MS. Patches that we in IT were FORCED to deploy before proper testing. Guess who has control of the process in our organization now?

    3. Re:Not MS' problem by l4m3z0r · · Score: 1

      Again I say this is the fault of IT. In your case the managers that "FORCED" you to deploy before testing. The article is mainly concerned with the volume, limit the number of patches. Thats great, just leave vulnerabilities unpatched.

      And what's so heinous about it?

      Where I come from you are held accountable for your performance. And that includes no protection by blaming the consultant, if you hire a consultant and he fails, you AND the consultant are terminated.

    4. Re:Not MS' problem by Anonymous Coward · · Score: 0

      You're assuming the "Management" was anywhere near his end of the food chain. If the CEO says I want it now, you do it now. Then when it breaks he wants you on a platter. Your job as an expert is to detect the potential damage, and mitigate the damage when processes outside your control happen. A half-witted CEO is a process outside your control as much as a lightning bolt. Try testing 200 applications every couple of days for minor bugs with two people while performing other duties. On a side note, the CEO has already denied your request for more people.
      You need to come to terms with the fact that the larger the company, the less control IT departments may have. In fact, if the comany is big enough to have an accounting department you're screwed.

  9. WSUS by dotegg · · Score: 0

    Ever heard of Microsoft WSUS client? With it you can push out patches to all your MS clients immediately.

    1. Re:WSUS by LurkerXXX · · Score: 1

      Which reduces the time needed to test patches before rolling them out, how?

      The corporate folks that wanted patch tuesday already have WSUS servers. That's not the issue.

    2. Re:WSUS by Anonymous Coward · · Score: 0

      I run a WSUS server in a large org with many funky mission critical apps. All of our machines are WAY behind on patches, until I was hired they were only releasing new patches every few months via login scripts, and the only patches released were the most critical ones (they averaged about 2 released per month!). They did no testing on the patches, and despite releasing so few caused problems on three different occasions (that I know of). Over time the amount of needed patches grew into the hundreds for some machines.

      With WSUS I deploy the newest patches plus a selection of old patches to a test group of IT staff and actual conscripted end users. Each new cycle I move the patches which make it through the test group onto all computers and then apply the next set of patches to the test group. I've caught 4 patches that caused trouble and only had one slip through and cause real problems on a few machines. Of course I still have hundreds of different patches needed, but every month that number shrinks.

  10. Patch Tuesday by Anonymous Coward · · Score: 2, Insightful

    My understanding is that they basically did it to allow IT guys to schedule their downtime and patching, instead of having to scramble every time MS releases a patch in the middle of the week. Which is how it used to work, up until 2003 or so.

    1. Re:Patch Tuesday by guruevi · · Score: 1

      From what I remember (it's only been 4 years, don't you remember anything? Or were you too young?) is that Microsoft started to grow a clue about security and had to bring out a patch to their Operating System as good as every single day (for ME, XP, ...). Of course this was to the great amusement of press, Netcraft and *nix sysadmins that boast 100's of years of uptime and Microsoft's marketing machine decided that: if we bring them out only once a month, we can combine them in a roll-up and it won't look all that bad anymore. They gave it the spin of 'easier for sysadmins' but real sysadmins knew you could schedule them (at least back then, haven't been using Windows lately but I noticed my parents' machine automagically reboots at night - creepy isn't it) either within your organization or locally.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
  11. The Problem is Volume by Sean0michael · · Score: 1

    It sounds like the problem is not that they only come out once a month, but that so many are released that it takes a long time to apply the patches. If they released one patch every day, it would still take a while to patch every system, especially for large companies or companies with tons of computers.

    It sounds to me like the only real solution is to make better code so that you do not have to release patches as often. It might just be an inevitability that IT must live with.

    --
    Funtime Candy Wow! - my plan for eventually conquering Japan.
  12. I call Bullshit on the Red Bull by The+Media+Mechanic · · Score: 3, Insightful

    "Known in some circles as Black Tuesday, the second Tuesday of each month in the last few years has become a kind of national day of mourning in the IT industry, as admins call all hands on deck and load up on pizza and Red Bull for the long night ahead."

    I call bullshit on this anecdotal bit of trivia. Is the author of the article actually suggesting that some companies rush to test the new Winblows patches all through the night on Tuesday so that the patches are ready to deploy on Wednesday ? This sounds like a fresh steaming load of bullshit... what places actually force their employees to work ridiculous hours like this just due to an arbitrary vendor schedule! I would not work at such a place, regardless of the amount of free pizza or Redbull available.

    My point is that this bit of exaggeration in the article has no basis in fact and should be supported by quotes from someone who actually enforces this policy at their IT department.
    --
    I can throw as many stones as I wish; my house is made of transparent aluminum.
    1. Re:I call Bullshit on the Red Bull by Zontar_Thing_From_Ve · · Score: 3, Informative

      Is the author of the article actually suggesting that some companies rush to test the new Winblows patches all through the night on Tuesday so that the patches are ready to deploy on Wednesday ? This sounds like a fresh steaming load of bullshit...

      You may be right. My previous job was with a company that did a lot of VAR stuff, including various email systems. It didn't matter to us what you wanted - Notes, Exchange, Unix, anti-virus, anti-spam - we could sell you whatever combinations you wanted. I didn't work with Exchange, but the Exchange guys told me that in the past they used to rush out and patch systems with every "critical" Microsoft patch release and then they applied some patch that totally broke Exchange. The patch had nothing to do with Exchange, but it broke it. It took hours to fix the broken servers. After that fiasco, we regarded all Microsoft patches as suspect and we had a group in another state that one of their jobs was to test new patches on Exchange servers and see if Exchange still worked. It didn't matter to us how "critical" Microsoft considered a patch. We didn't patch any of Exchange servers until our test group gave the OK, which was usually a month later.

    2. Re:I call Bullshit on the Red Bull by MSFanBoi2 · · Score: 1

      I totally agree. Patch Tuesday hits, we test in the lab thru Thursday and on Friday push the updates via WSUS 3.0.

      I really don't know what the problem is. It only takes about 4 hours of testing and less than an hour to push. No late nights, no impact, it just gets done.

      Of course MS can always go the Apple route and wait months to release 100 MB+ patch rollups...

    3. Re:I call Bullshit on the Red Bull by FST777 · · Score: 1

      That's even more ridiculous, since said company spends valuable man-hours on researching a fix from a vendor for a bug in a program from said vendor that might break another program from the very same vendor. The vendor should have done that testing thoroughly and repeatedly, and should have made the results public.

      If such a thing happened with any other software package, we would charge the vendor with the costs and lost revenue. I really long for the day that we replace all of the MS crap floating around on our systems. We are getting there.

      Actually, we have a similar problem: the update from IE 6 to IE 7 breaks our mailapp (third party). To fix this, we are told to upgrade said mailapp for the tiny sum of 8,000.00. So IE 7 costs us eight grand (which upper management is not prepared to pay, since the mailapp sucks already and we probably will replace it with something homebrew).

      --
      Free beer is never free as in speech. Free speech is always free as in beer.
  13. My opinion by t00le · · Score: 1

    I am all for regular patches, whether weekly or daily for that matter.

    The majority of home users I hope patch occasionally, which alleviates a fair amount of trojan'able machines. On the corporate side we personally run internal Windows Update Servers where we can auto-schedule approved updates and push them out on a schedule. The whole concern about the corporate side is laughable since most large Windows shops have some form of patch management, (granted my reference is from ten large corporations) whether internal update servers or pushed updates using something else. The bottom line is Microsoft knows they have security problems and they update it on a schedule.

    My concern is not the people that have licensed copies of Windows, but the ones that do NOT and are unable to patch their systems. I think a good portion of the machines that are compromised are non-licensed or cracked versions, which is somewhat amusing.

    Why would Microsoft keep bootleg copies from being updated seems more logical to make it "non-networkable" instead of "non-updateable"

    --
    When the only tool you have is a hammer, every problem looks like a nail
    1. Re:My opinion by Anonymous Coward · · Score: 0

      Why would Microsoft keep bootleg copies from being updated seems more logical to make it "non-networkable" instead of "non-updateable" Regardless of why, they do it. Even known illegitimate copies of Windows receive security updates by Automatic Update, they just can't be manually downloaded from Windows/Microsoft Update (WGA required). It's a Good Thing.
    2. Re:My opinion by Anonymous Coward · · Score: 0

      you can still get critical updates on cracked copies as long you choose to use automatic updates. if youre using a cracked copy you cant go to windowsupdate.com and get updates and you cant get the optional software updates.

  14. Fix The Real Problem by EXTomar · · Score: 2, Insightful

    The original reason why "Patch Tuesday" was created was because too many were giving feedback to Microsoft that their patching process was far too disruptive to their enterprise. Before "Patch Tuesday", you could check any particular machine, at any time of day or week, and regardless of its role or usage it may have a patch pestering people that it needs to be applied and the machine rebooted. "Patch Tuesday" essentially is a "work around" to condense all of these patches that could be highly disruptive into a smaller, brief time frame.

    The real problem is the patching system Microsoft chose is highly disruptive. Too many still demand user attention even if applied remotely by an administrator. Although less often, too many still require a reboot which is a larger disruption to the user's work. Should Microsoft consider changing how patching is done so that it isn't so "hands on" and pesters the users and administrators to take action? Improve patching to the point where patches can be applied painless from the IT Center and "Patch Whateverday" goes away.

  15. My Thoughts by KenshoDude · · Score: 5, Informative

    I am the Sys Admin for ensuring that our roughly 1800 desktops and notebooks get updated with the latest updates. Microsoft's strategy is the very least of my concerns. The patches show up on WSUS the Wednesday morning after they are released. I read up on them, noting any "caveats" in the KB articles and inform our help desk if I find anything signficant. Then, I set my approvals and decline any superseded updates. The clients check in and install the updates over night. I am not sure where all this talk about long nights with Red Bull and whatever come into play. If we have mission critical systems, we withold approval for that group for a week or so until we are confident that there are no undisclosed "caveats." Super simple.

    I like having a regular schedule for updates. But I wouldn't mind a little more frequency. Why not the first and third tuesday of every month? Sounds reasonable to me.

    Now if were only that easy for all the other software vendors out there like Adobe (Acrobat / Flash), Sun (Java), and so on. Where are their enterprise patch management solutions? Why can't I configure my Java clients to check into to one of my servers to automatically apply security updates? Instead I have to spend more money on a 3rd party patch management solution. And I haven't found one yet that is as reliable and simple as WSUS.

    1. Re:My Thoughts by Brad_sk · · Score: 0

      Nice to see some reply giving MS their deserved credit and not just crying likr other slashdot posts. I am not saying MS has THE best solution, but I do agree that their solution is better than others in the industry (inluding Linux) and yes, may be twice a month is better.

    2. Re:My Thoughts by Anonymous Coward · · Score: 0

      Java gave us a problem because it could not be updated automatically. We deployed an image with a broken version of java accross about 1000 workstations, in several months long rollout at our community college.

      Any browser loading this java dies, and we must log into machines to remove the old version ourselves, and then install the new one... we have removed admin rights so our users can't do it alone. Upgrading alone fails because Java 1.3 runtimes co-inhabiting with old versions (our broken one still crashes things until it is explicitly removed.) In any case, our team lead (the same one who failed to test Java when creating the image) refused to do anything, claiming that java would update itself [nope, even if set up in the Control Panel, java needs 1) user intervention 2) admin rights, which ours lack]. He stalled and let the issue die, though I repeatedly mention it. I still find machines that haven't been hand-patched, and the master image STILL hasn't been fixed. Time to quit.

    3. Re:My Thoughts by TheSkyIsPurple · · Score: 1

      So, that means that desktops need admin visits, right?
      Don't those get logged?

      Can't you come up with a tally of how many machines have need hand care, and how long it's taken... and say "whether or not it's supposed to work, in these cases it ACTUALLY didn't work"?

  16. Volume? Where? by Anonymous Coward · · Score: 0

    The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.' http://www.microsoft.com/technet/security/current. aspx
    What volume is he referring to? Microsoft release seven (7) patches for the month of May. There were a whopping 6 for April. I am the person doing patches for a Fortune 500 company. More or less, ITMU does it for me. The sky is not falling.
  17. Mod parent up Re:I call Bullshit on the Red Bull by vic-traill · · Score: 1

    Workstation patches roll in enterprises of any size via WSUS or similar. As far as testing of workstations patches go, that's Microsoft's job. You hold the w/s patches for a few days on your WSUS server, wait to see if there are any issues, and if not, let them roll. If we had to test w/s patches on a per patch basis, we wouldn't be able to run the enterprise. If we were patching w/s's outside of a WSUSish service, w/s's wouldn't get patched.

    So, WSUS manages the roll-out of patches to workstations, and you can roll 'em one by one, or in bulk, whichever is your druthers.

    The server side is obviously a different kettle of fish. We're not an MS shop in terms of our primary directory (although we sync our directory to an AD instance) or file and print services, so rolling to our MS application servers is a not-so-onerous exercise.

    --
    [17] Leary, T., White, C., Wood, P. R., Bhabha, W. D., and Wirth, N. Lambda calculus considered harmful. In Proceedings
  18. Re:End Patch Tuesday by businessnerd · · Score: 4, Insightful

    Except for the fact that Linux also requires patching. Every other day I have a little star on my desktop notifying me of updates to various libraries, applications, and yes the kernel itself. Mac's have patches too. This is not necessarily a Windows vs. , this is about what the best way of releasing patches is. It's an Incremental vs. Bulk release debate. MS chose the bulk method. Is that a good decision? Maybe, maybe not. Regardless of the OS, patching is always required. No piece of software is bulletproof.

    --
    "It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
  19. That's the Problem by bill_mcgonigle · · Score: 5, Insightful

    It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

    Your comment is accurate, and gets to the heart of the problem. The current system minimizes cost, at the expense of security.

    The pundit would rather companies get more staff, do rolling testing, etc., whatever it takes - to maximize security.

    Now, as a non-user of Microsoft products and a victim of attacks by unpatched machines, some of them corporate, it's clear that the current strategy just shifts the costs off of the companies and onto me. If it just crashed their networks I couldn't care less. But it's more than that.

    So I need to side with the proposal - the users need to improve their security. They can do this by having rolling patches from Microsoft or picking a more secure product to use. I don't care how they do it, but they need to stop expecting me to pay for their poor performance.

    Unfortunately, liability is poorly defined in this realm, otherwise I could theoretically sue for damages, and their insurance company would make sure they were in good shape or charge them through the roof for being in bad shape.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:That's the Problem by snoyberg · · Score: 1

      We need a trial case against some Fortune 500 that has spam bots. Perhaps a victory in a case like that will turn the tide.

      --
      Thank God for evolution.
    2. Re:That's the Problem by erik_norgaard · · Score: 1

      No. They should make patches available as soon as possible. The argument that administrators needs time to test patches only makes sense if patches are available before rolling these out on production systems, whether patches are published a given day of the month or not doesn't change this.

      Making patches available as soon as possible, the administrators can schedule testing and patching as most convenient, maybe weekends are preferred for rolling out patches. And they can decide which patches to fast track, and which to delay to the regular updates according to how their systems are affected.

      What should be changed is that Windows update by default should download patches as published and delay installation till shutdown, unless marked critical. A critical update should cause a information message asking the user whether to update the system now or at shutdown. This causes the least user annoyance, and exactly that is what causes systems not to be updated. And of course, the administrator should have the ability to change this behavior to schedule updates at specific times on corporate networks.

    3. Re:That's the Problem by gad_zuki! · · Score: 1

      This policy isnt written in stone. MS has many times pushed out an out of cycle patch if it was urgent.

    4. Re:That's the Problem by kabocox · · Score: 0, Flamebait

      Now, as a non-user of Microsoft products and a victim of attacks by unpatched machines, some of them corporate, it's clear that the current strategy just shifts the costs off of the companies and onto me. If it just crashed their networks I couldn't care less. But it's more than that.

      So I need to side with the proposal - the users need to improve their security. They can do this by having rolling patches from Microsoft or picking a more secure product to use. I don't care how they do it, but they need to stop expecting me to pay for their poor performance.


      Why the hell should I change anything about how we do business to suit your wants or needs? If we are doing business without problems with somewhat hacked machines, but those hacked machines are bringing down your computers, why should we even care?

      Please enlighten me why I should spend resources/effort on fixing your problem? I don't have a problem, you have the problem. You can't change my behavior, and I'm happy doing what I want. Why should I care if our company shits on you, and you can't do anything about it?

      Answer: I won't change until a group slaps my company and forces me to change.

    5. Re:That's the Problem by bill_mcgonigle · · Score: 1

      Right, that's why we need some liability case law to establish that I can sue you for attacking my machines due to your negligence. Once that's true, your insurance company will do the slapping.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:That's the Problem by pacalis · · Score: 1

      The current system minimizes cost, at the expense of security.


      Security reduces the costs of lack of security. That's all it does.

      So there's a point where increasing investments security becomes more costly than loss of security. Current system seems like a good balamce to me.

    7. Re:That's the Problem by bill_mcgonigle · · Score: 2, Insightful

      So there's a point where increasing investments security becomes more costly than loss of security. Current system seems like a good balamce to me.

      And more importantly the current system shifts cost off of those with poor security and onto everybody else. Since there's no downside for those doing the shifting, it is a good state of affairs for them. The trouble is with all those insecure goats, the commons are becoming bare.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    8. Re:That's the Problem by imroy · · Score: 1

      This policy isnt written in stone. MS has many times pushed out an out of cycle patch if it was urgent.

      Like the time their WMP DRM was cracked. Sure, something like DRM is given high priority and the fix is pushed out in a day or two. But stuff that can result in compromised systems across the Internet (like spam bots)? Nah, wait until next month to fix that. Makes you wonder about their priorities

    9. Re:That's the Problem by Allador · · Score: 1

      Making patches available as soon as possible, the administrators can schedule testing and patching as most convenient, maybe weekends are preferred for rolling out patches. And they can decide which patches to fast track, and which to delay to the regular updates according to how their systems are affected. This doesnt really work in the real world. As soon as patches are released to the world, they get very quickly reverse engineered, and massive active exploitation tools follows by a few days to a week.

      This effectively forces admins to install patches asap as soon as they come out, as there's only a short window before the active exploits flood the wild.

      The net result of all this is that MS releasing patches once a month is effectively better security, even if it means they hold on to some patches for a couple weeks. At least in the general case. There are always exceptions.
    10. Re:That's the Problem by quux4 · · Score: 1

      The current system minimizes cost, at the expense of security.

      No, it finds the best balance between the two. Consider this: there's a vulnerability known to the white- and blackhat communities, but it isn't being widely exploited yet. However, the minute the patch rolls out, it's worldwide news, and all the script kiddies are reverse engineering it and automating the exploit so they can compromise unpatched systems by the hundreds or thousands.

      So, yeah, let's take that 1x/month script kiddie window, and have it 3-7 times a month (MS have been releasing about that many patches per month lately). Let's make everyone choose between rebooting 1-2 times a week... or having unpatched vulnerabilities known not to a small black|white-hat community, but a huge botmaster/scriptkiddy/spyware community (who are finding profit in the excercise).

      That'll increase security and lower costs, right? And for you, the non-MS user ... it'll definitely lower the number of scripts strobing your firewall and costing you pennies per month in bandwidth charges, eh?

    11. Re:That's the Problem by mr_mischief · · Score: 1

      Nah, we know where their priorities are. Stock price, profit, and market share are their priorities. The order is not necessarily right, but I think it probably is.

      The reason stock price is so important at MS is that so many of the employees hold large numbers of shares. The best way to motivate employees to look after shareholder interests is to get loads of shares into their hands. That way, shareholder interests benefit from the self interest of the people inside the company. It great news to the top shareholder (Gates, with over 900 million shares according to Yahoo Finance) when the employees all want to make him richer.

  20. This round broke live update... by Tmack · · Score: 0, Troll
    At least for me, I applied the "IE6 cumulative service pack blah blah blah" update that the windows update thingy told me needed updating, rebooted, and about 5 minutes later, it popped up again, asking to install the same thing. Since I dont even use IE, I dont really care, I just wish the updater would quit thinking it needs to update what it just updated!

    tm

    --
    Support TBI Research: http://www.raisinhope.org
  21. Really? by Anonymous Coward · · Score: 0

    The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.

    I have to question this statement. I work (in Engineering, not IT) at a large company with over 100,000 employees. I don't know the details, but the IT department has the patching thing down to a science. Like clockwork, we first get an email when Patch Tuesday rolls around telling us that new patches are coming in the next couple of days and they'll require a reboot. Then by Thursday night, every PC is automatically patched and rebooted. If you shut off your PC every night, the patch simply happens next time you boot up (get some coffee while you wait). Otherwise it happens when you're not there, late at night. If you're actually working during that time, you have the option to delay the reboot. All in all, the process is completely seamless.

    Granted, I don't know how much testing they do -- or how much they can do in such a short period of time after initial release. We had one patch a few weeks ago (not a Patch Tuesday patch) that apparently hosed the video drivers of some small percentage of deployed PCs, but the fix was rolled out quickly. Thankfully my PC is so goddamn old that it was unaffected. And of course, I still do my real work on the unix side, so a dead PC would only kill my occasional MS Office stuff. Can't say that about most people, though.
  22. Cmon....the patch management tools are FREE by zerofoo · · Score: 1

    Windows Server Update Services is free and it works like a champ. This free tool has enabled every machine on our networks to remain up to date on patches. It usually takes a couple of days for all of our machines to check-in and install the updates due to roaming users. It only requires a few clicks on my part.

    I'll admit that it doesn't make testing any easier, but it does give you the ability to block patches until you have tested them for stability.

    I usually test patches for a few days against major apps before approving the updates for installation.

    If you have a large number of apps that continually break, then the problem is not patch management, it's vendor management.

    -ted

  23. Makes sense to me! by Anonymous Coward · · Score: 0

    I never have anything going on on Tuesdays...

  24. WSUS works well for me by GreenEnvy22 · · Score: 1

    WSUS combined with good AD group policy rules keeps my 60 or so clients happily updated, I rarely have to manually go download and install a patch.

  25. I hate "rollups". by khasim · · Score: 1

    At least with "Windows Update" I can, somewhat, limit the amount of crap going onto my systems.

    But a far FAR better solution is Debian's approach. I get TINY patches and ONLY for what is specifically running on my system.

    It is so much simpler and easier to test with that approach.

    Particularly when compared to things like WinXP's sp2 (with firewall) approach.

    1. Re:I hate "rollups". by peragrin · · Score: 1

      while ideal MSFT couldn't do that.

      according to MSFT own developers the windows codebase is filled with circular dependancies. Think the backup department of the government department of redundcies.

      Unitl they actually break compatibility, and actually rewrite the codebase instead of just porting windows XP to the Win2k3 kernel, and make the whole system modular, your going to get massive patches.

      --
      i thought once I was found, but it was only a dream.
  26. Re:End Patch Tuesday by fred+fleenblat · · Score: 1

    The fine point is that you can get away with not patching desktop linux/unix/macos machines for *years* w/o any problems. Only full internet facing servers really need to be up to date on the patches. In contrast, any windows box that can surf the net or receive email is a sitting duck, whether it's behind a firewall or not.

    What makes them sitting ducks? Probably a lot of factors. Throwing patches at machines is a coping strategy, not a solution.

  27. They should have a patch hour by niceone · · Score: 1

    They should have a patch hour, it would be every day - just like a happy hour, but without the half price drinks. Um, or the happiness.

  28. Leave it! by antdude · · Score: 1

    I actually like this monthly Tuesdays schedule (gets me excited ;)). Once in a while for urgent updates.

    I do also notice sometimes the fourth Tuesdays of each month might have other non-critical releases.

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  29. Re:End Patch Tuesday by timbck2 · · Score: 1

    Apple tends to release patches in bulk as well (bundled into a "Security Update"). The only difference between Microsoft's bulk release method and Apple's bulk release method is that Microsoft's is on a schedule.

    --
    Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
  30. Re:End Patch Tuesday by blhack · · Score: 1

    I would liken linux patches to a database app i recently wrote for my company. I work in the automotive industry, and the app was designed to look through a database for a specific set of parameters. Basically it alerted people via email when certain types of vehicles got checked into our inventory. The app was done, it ran smoothly without crashing, but most importantly it ran. That was a couple of weeks ago. Now, i might be driving home from work, or sitting at my desk reading /. and an idea might *POP* into my head for a way to make the app just a SHADE faster, or some very obscure but totally cool other functionality that it could have. THAT is a linux patch, something that maybe isn't completely necessary, but is pretty darn cool, and might protect against an obscure sort of attack.

    A windows patch would be something much more critical. IT would have been if i had released my app onto the webserver a couple of days before it was actually ready, then realized that it had some HUGE flaw (red cars crash the system or something crazy), but that i couldn't recall it, because that would involve re-signing up a few thousand people up for alerts...or migrating the data over by hand.
    Now pretend that half of these MISSION CRITICAL patches that i release also create other HUGE mission critical problems. Say, i fixed red cars crashing the system by calling them rouge, but now all the old RED cars are still there, now there are TWO of everything....so now if you search through the DB by VIN or something like that....you find two of everything...CRAP!!! BUT OH NO!!! sometimes we actually have the same car checked in twice intentionally!!! SO how do you tell which is whic0h!?!?

    SO yes, linux also releases patches all the time, but they are MUCH less critical.

    --
    NewslilySocial News. No lolcats allowed.
  31. Billg's Response by Anonymous Coward · · Score: 2, Funny

    End patch Tuesday? That's the dumbest fucking idea I've heard since I've been at Microsoft.

    1. Re:Billg's Response by Gazzonyx · · Score: 1

      For some reason, that just never gets old! I thought that it would be one of those annoying meme's, but it's got lasting value. It's just as funny as when I first read it. Can we officially replace underwear gnomes profit with this one? Can we vote on it?

      --

      If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

  32. Corporations have no one to blame but themselves by realmolo · · Score: 1

    In my experience, the whole reason that you have to "test" patches on corporate machines is that the vast majority of the custom-made and "niche" software that many businesses rely on is HORRIBLE. Bug-ridden, non-standard, breaks every rule. Hell, a lot of it is still 16-bit Windows (and even DOS) software with only minor modifications to keep it working under modern OSs. And so, every update causes problems, because it only barely works anyway.

    If corporations were better at updating their software (and determining which software to use in the first place), they wouldn't have to be scared of "Patch Tuesday".

  33. Re:End Patch Tuesday by suv4x4 · · Score: 1

    It's an Incremental vs. Bulk release debate.

    There's of course the option of releasing it both ways and people can click an option in Windows Update which they prefer.

    Of course, if you release patches both ways, it leaves the bulk updaters more vulnerable, as hackers would reverse engineer from the earlier release.

    So the immediate patches should be only for known exploits already in the wild, and bulk for the rest.

  34. Re:End Patch Tuesday by harry666t · · Score: 2, Interesting

    Patching MS products is broken...

    I haven't patched anything from MS since years, but as far as I recall there was always some downtime due to reboots after applying a patch. I think MS had to release patches monthly, else there would be more downtime. Now that the Patch Tuesday goes to /dev/den it is going be much harder to schedule the updates. How this could be fixed, dunno. One thing that comes into my mind is that I never had to reboot my Debian box after applying any updates (except after kernel update). I guess Windows needs to be more modular, so people could swap broken components on the fly. Dunno, apt ftw.

    I think the Patch Tuesday is here to stay, at least 'till the end of this year (vista sp1?).

  35. Seriously. by lullabud · · Score: 1

    I've had 10% of our company in my office in the last 2 days with that svchost BS. *sigh*

  36. Re:End Patch Tuesday by businessnerd · · Score: 1

    While many of the patches in Linux are just as you say, merely enhancements (many OSS apps seem to be a constant WIP), there are still plenty of patches that are bug fixes. I'm pretty sure that when Mozilla releases a patch for Firefox, they are not adding enhancements, or re-writing the code to be faster (unless the way they wrote it caused serious issues). Most Firefox patches are bug fixes. That's why they change my version from 2.0.0.2 to 2.0.0.3 and not to 2.5 or 3.0. That's why you also call it a patch, and not a full release. Patches are critical and done when absolutely necessary. Adding a spellchecker "cause it totally be cool" is not critical or absolutely necessary, and that's why that stuff is reserved for bigger releases.

    --
    "It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
  37. No by Kjella · · Score: 2, Insightful

    A bug might have been there for one year, two years, five years. The chance someone will find it by accident in the next two weeks (average delay to release) is rather slim. On the other hand you know the moment the patch is out, hackers will reverse engineer it within a short period of them. That leads to the following conclusions:

    1. You have to patch within a short period of release
    2. One patch may break any functionality, so you must test all of it
    3. If Microsoft releases patches all the time, you must test all the functionality all the time

    In 99% of the companies out there, that's just not going to happen. I love getting daily patches, my desktop or home server isn't a critical business machine. I'm mostly interested in avoiding someone hacking it so I have to set it up again, far more than a broken patch. At the very least that leaves the machine in a "known broken" state that hopefully be fixed by another patch, where as a decent virus infection might end in a reinstall. For many a corporate machine down means you're down. Sales lost, salaries roll and nothing gets done. Sometimes data gets stolen but most of the time the cost is downtime - whether it's broken software or infected software. Quite often the solution is the same - rollback to a known good state (after you've figured out how to not get reinfected). Under those conditions I see why they prefer a mad scramble every patch Tuesaday instead of a mad scramble all the time.

    --
    Live today, because you never know what tomorrow brings
  38. Re:Corporations have no one to blame but themselve by Bill,+Shooter+of+Bul · · Score: 1

    I imagine thats a part of the problem, I really don't know what percentage of the problem is due to bad cooperate software. I've seen some terrible stuff as well. It sounds strange now, but I'm guessing that may have actually been the fastest( or at least the cheapest) way to do it back when it was done. Microsoft has produced too many ways of doing everything, and doesn't always do a good job maintaining computability for all of those ways.

    --
    Well.. maybe. Or Maybe not. But Definitely not sort of.
  39. Missing A Key Reason by theborg1of4 · · Score: 1

    All this reasoning misses a key point. If Microsoft releases patches on a very frequent basis, IT departments aren't necessarily going to patch their infrastructures (remember we're talking potentially about tens or even hundreds of thousands of nodes) with the same cadence. So in many cases those infrastructures are going to lag behind the current patch level.

    But once a patch is made available, it provides an opportunity to reverse engineer the patch to determine what the defect was. This gives hackers the opportunity to devise attacks that leverage the vulnerability.

    So you see what happens: if Microsoft releases too frequently it creates a large window of opportunity for infrastructures to remain unpatched and therefore vulnerable to exploits.

    Microsoft chose a monthly release strategy as a balance between too often and not often enough. It's not perfect but the alternative is far less desirable.

  40. WSUS 3.0 + patch fixes it .. or so they say by bilbus · · Score: 1

    I have upgraded to wsus 3.0, removed office updates from the server, and installed the hotfix. The problem only seems to happen if your scaning for office fixes also.

  41. Duh! by ady1 · · Score: 1

    The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time. The patches released so frequent are never about security or reliability. They are only to play a blame shifting game.
  42. For some people... by Anonymous Coward · · Score: 0

    For some people rebooting is an unreliable way to execute...

  43. Re:Corporations have no one to blame but themselve by BLQWME · · Score: 0

    I beg to differ- the reason to test patches is not just for apps but also for the operating system. Case in point I offer the fiasco that came from MS04-016 (I'm pulling from memory here). That patch zombied a lot of machines.

    --
    "Nobody shoots anybody in the face unless you're a hit man or a video gamer"- Jack Thompson
  44. End patch tuesday? by geekinaseat · · Score: 1

    You've got my vote, I'd love a four day week once a month! If only we could get rid of "Meeting Monday" and "Wait for the end of the day Friday" too!

  45. Re:End Patch Tuesday by badc0ffee · · Score: 2, Informative
    But, I have switched to Linux. I still have to boot into Windows to download and apply the patches... if I remember to. Otherwise I just keep getting my daily Linux enhancements via yum and forget about Windows.

    As my weather radio keeps reminding me when there is a thunderstorm alert: "... and stay away from windows".

    --
    1011 1010 1101 1100 0000 1111 1111 1110 1110
  46. One solution: Shavlik by bev_tech_rob · · Score: 1

    Shavlik's Patch deployment software works real well in that aspect....you can pick individual machines, OU's, IP ranges or any other combination you can think of. Can decide which machines get which patches....you can configure the time of the patch deployment, when the machines will reboot after said patches are installed.....quite a large number of ways of deploying patches...

    This is what we use at my place of work, but still takes quite a bit of time tending to a large number of machines, especially waiting on the server engineers to give you permission to proceed, QA testing, etc......

    Still..better than having to touch each machine one at a time....

    --
    You're messin' with my Zen Thing, man.....
  47. Secure your system on our schedule by Dancindan84 · · Score: 1

    Cancel or Allow?

    --
    "Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
  48. Why not use WSUS by majortom1981 · · Score: 1

    If you use wsus you would have nothing to worry about. Why complain? Just set a set time each day and the computers will download the updates themselves. yes it works for the office problems too. Plus its free.

  49. We use patchlink by arrgster · · Score: 1

    They test patches before we get them and they automate the deployment. You can also push out other software patches and files. It's not a perfect system but it does make life a lot easier than just using MS updates.

  50. It's in my diary.. by Dynamoo · · Score: 2, Informative
    Patch Tuesday is in my diary (well, actually the Wednesday because the patches are announced in the evening UK time). I have a change control provisionally made for EVERY post-patch Tuesday Saturday to cover servers, and I also have an entry for the Friday before patch Tuesday when the advanced notification is made.

    This is the way it goes..
    Friday: Look at the advanced notification to get an idea of the scale of the patches. Once or twice a year there a none.. yippee!
    Wednesday: In the morning we closely analyse the patches to figure out the impact on our organisation. Servers and clients are differently impacted so we look at this to see if we will need to patch servers. Patches are tested on some representative computer systems.
    Thursday: raise the inevitable paperwork for any system changes and monitor for any issues.
    Friday: Check for issues with the patches and then authorise for client distribution via WSUS.
    Saturday: If necessary, patch those servers that are vulnerable. Claim overtime. Yippee.

    We know in advance when this is coming up. We can make plans. We ensure that someone always looks at the patches on Wednesday morning and does the analysis. It's a monthly event that we don't miss. This works pretty well.

    Sure, sometimes you need to apply an out-of-cycle patch.. these are rare but Microsoft seems to understand that they are needed. If we miss it, then we'll alway pick up on it again later.

    Yeah, hardcore sysadmins might like patch and reboot PCs every couple of days or so, but most sysadmins have other things to worry about than constant patching and in my view Microsoft have the balance about right. (One of the few things I like about them!)

    --
    Never email donotemail@WeAreSpammers.com
    1. Re:It's in my diary.. by homebrandcola · · Score: 1

      > Sure, sometimes you need to apply an out-of-cycle patch.. these are rare but Microsoft seems to understand that they are needed.

      Such as the patch to fix a hole in their DRM that was exploited by FairUse4WM.

      This was clearly an emergency, and needed to be patched out of cycle.

    2. Re:It's in my diary.. by Anonymous Coward · · Score: 0

      well, it surely takes log time to test...
      I wonder how much that costs...

      and...
      are gnu/linux server-distribution different?
      i mean... they need to be patched, too...

  51. Oh, really? by Stonehand · · Score: 1

    Are the hundreds of SuSE security announcements sitting in my GMail account illusory? There have been nineteen since the beginning of March, some of which cover multiple issues, and which include problems with the kernel, XFree86, even security-related packages like krb5 and gpg...

    And they're not necessary trivial issues. Among the multiple security-related bugs in today's update, for instance, include a potential remote exploit, a privilege-escalation exploit, and a somewhat-remote DOS attack.

        - CVE-2006-6106: Multiple buffer overflows in the cmtp_recv_interopmsg
                                          function in the Bluetooth driver
                                          (net/bluetooth/cmtp/capi.c) in the Linux kernel allowed
                                          remote attackers to cause a denial of service (crash) and
                                          possibly execute arbitrary code via CAPI messages with a
                                          large value for the length of the (1) manu (manufacturer)
                                          or (2) serial (serial number) field.

        - CVE-2006-5753: Unspecified vulnerability in the listxattr system call in
                                          Linux kernel, when a "bad inode" is present, allows local
                                          users to cause a denial of service (data corruption)
                                          and possibly gain privileges.

        - CVE-2007-1357: A denial of service problem against the AppleTalk
                                          protocol was fixed. A remote attacker in the same
                                          AppleTalk network segment could cause the machine to
                                          crash if it has AppleTalk protocol loaded.

    --
    Only the dead have seen the end of war.
    1. Re:Oh, really? by fred+fleenblat · · Score: 1

      Funny, but the three you mentioned all require some proximity on the part of the attacker.

      * The bluetooth attacker has to actually be within 30 feet of you. You should be more worried for your own safety than about what's going to happen to your machine.

      * For the bad inode one, you have to ALREADY BE LOGGED INTO THE MACHINE before you can attack it. If I'm logged into a windows machine, there is nothing further I need to do to attack it.

      * The appletalk attacker has to be on the same network segment, i.e. probably in the same building with you. You can have your network admin track down the packets and have him/her arrested if you feel like it.

      In contrast, the windows vulnerabilities always seem to be someone sending you a malicious email that masquerades as a cursor file or wallpaper, or just visiting a website will download something nasty. Things that can be done from the other side of the planet through 18 layers of proxies and reflectors and when it's done they have complete control of your computer.

      That kind of stuff just doesn't seem to happen to linux, unix, or macos boxes as often. Mind you, it can happen I'm not saying they're immune, but unpatched linux boxes just soldier on, especially if they're behind a corporate firewall or home NAT. The same cannot be said of windows.

    2. Re:Oh, really? by coryking · · Score: 1

      > In contrast, the windows vulnerabilities always seem to be someone sending you a malicious email that masquerades as a cursor file or wallpaper...

      You mean, local exploits? Local exploits like "For the bad inode one, you have to ALREADY BE LOGGED INTO THE MACHINE before you can attack it. If I'm logged into a windows machine, there is nothing further I need to do to attack it"?

    3. Re:Oh, really? by blhack · · Score: 1

      In linux, the default account is set up as a user, with only VERY minimal rights outside of /home/$username

      IN windows, the default account is setup in HOLYGODADMINMODE

      I've got a demonstration for you:

      Sit down at a linux box as a user. Execute rm -rvf /....see how long it takes you to get the machine back into running order
      Now sit down at a windows box. Execute del C:\*.* see how long it takes you to reinst

      ------NO CARRIER------

      That is the difference.

      --
      NewslilySocial News. No lolcats allowed.
    4. Re:Oh, really? by fred+fleenblat · · Score: 1

      sending a malicious email is not my definition of a local exploit. you don't have to be logged into a windows machine to send malicious email to a user on that windows machine.

      if you're going to blame the user for opening the email, you might as well blame the user for running windows, and that's probably where we would agree.

  52. Liability issue by Stonehand · · Score: 1

    Microsoft itself is fairly insulated from liability issues with their licensing agreements.

    A business that knowingly delays deployment of a security-related patch for reasons of convenience, and suffers loss of customer data or other issues that would otherwise have been prevented -- I would not be so certain that the business itself would necessarily be invulnerable to lawsuits from injured third parties.

    --
    Only the dead have seen the end of war.
  53. Re:End Patch Tuesday by Anonymous Coward · · Score: 0

    Probably a lot of factors. Throwing patches at machines is a coping strategy, not a solution. Are you serious? You seem to imply that fixing software bugs (which is the purpose of patches) is not a solution! When everyone writes perfect software, then we can get rid of patches. Until then, patches/updates/etc. will be necessary to fix bugs in released software.
  54. I've already ended "Patch Tuesday" by AndroidCat · · Score: 1

    After repeated experiences of the extremely awful "check for updates" software, which would lock out other apps from starting, including the task manager, I switched it from "notify" to "off". Now I'll do it manually on my own, thanks.

    It still puts a x-shield icon on the bar, and I can live with that, but if it nags me one more time that the automatic update is switched off, it will find that it can't live with that because I will hunt down that clippy-like code and make it non-executable.
    --
    One line blog. I hear that they're called Twitters now.
    1. Re:I've already ended "Patch Tuesday" by Anonymous Coward · · Score: 0

      Disable the Security Center service to stop those messages.

      Start,Run
      type in services.msc, hit OK
      find Security Center
      right click, select Properties
      Change startup type to Disabled
      Hit stop to stop the service
      Hit OK

  55. Darwin taught us: by Xymor · · Score: 1

    Diversity is key to survival.

  56. Unlike some other companies... by DangerTenor · · Score: 1

    Unlike others such as Oracle, Microsoft actually releases truly critical patches ahead of patch Tuesdays. Oracle's monthly (or is it quarterly) releases are totally inflexible, never release patches inbetween, and DBAs are months behind getting these patches in place because of the "sheer volume"...

    --
    Check out our infosecurity industry blog: http://securitymusings.com/
  57. Re:End Patch Tuesday by fred+fleenblat · · Score: 1

    >> You seem to imply that fixing software bugs (which is the purpose
    >> of patches) is not a solution!

    Fixing two bugs this month and eight bugs next month and three bugs the following, and this goes on for years at a time, tells me there are probably *thousands* of undiscovered security holes in the average windows+office install. They are fixing maybe 1% a month, probably less or the same as the rate at which they introduce new bugs. *That* is not a solution, and I'm not implying it, I'M SAYING IT OUT LOUD.

    If solaris or macos was that bad, I'm sure microsoft would waste no time issuing press releases to tell us about that. What do we get instead? "Every OS should have UAC!"

    That's the best they can do: fix 1% of the bugs per month and pretend like UAC is something other than a poorly implemented rip off of sudo.

    Well screw that. I'm typing this on a RHEL 4 box that I update/patch about once a year, if I get around to it. Total number of viruses, spybots, adware toolbars, keyloggers, popups? Zero.

    Why can't microsoft be as good as that?

  58. How about they stop changing my default browser... by rsmoody · · Score: 2, Interesting

    I don't care how often they patch. I JUST WANT THEM TO STOP FRACKING WITH MY DEFAULT BROWSER!!! This is the second month in a row that I have rebooted to be asked by Firefox if I want it to be my default browser. WTF, over?!?!?! It's MY FRACKING COMPUTER!!!!!!!! I know I know, switch to Linux, the point still remains. WTF is with this crap though?

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  59. Why is this M$ problem??? by nlinecomputers · · Score: 1

    If MS comes out with a patch, the company starts testing it out, then 3 days later MS comes out with another patch, the big corp now has multiple cycles of testing trying to go on at the same time, using up tons of IT resources, backing things up in the pipeline. If their testing cycle is 2 weeks, and MS releases 6 patches during those two weeks, the pipeline is now filled up with 12 weeks worth of throughput. Not fun.


    Why is that a M$ problem? Why can't your company just have an internal regular patch schedule? Any patch issued in the past 30 days is put on that end of the month test schedule. If the patch is super-critical then you'll have to break your schedule which is what M$ does anyway when a emergency patch is released. I'm not a large company I can keep up with such updates why must I wait because Lardtech, INC. isn't as fast?
    --
    Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
    1. Re:Why is this M$ problem??? by LurkerXXX · · Score: 1

      I'm not a large company I can keep up with such updates why must I wait because Lardtech, INC. isn't as fast?

      Probably because Lardtech pays MS a *LOT* more than you do. Their preference for a patch cycle beats yours because you don't make MS as much money.

      As for why can't the large company just have an internal regular patch cycle, waiting on all patches till the end of the month? Because of modern realities.

      Much of the time security holes are found by MS's internal folks, or 'good' security hackers which report holes to MS and gives them a reasonable amount of time to generate/test a patch before reporting them to the public. As soon as MS releases one of these patches, the bad guys leap on it, doing diffs between patched and unpatched code, trying to figure out exactly what it was that MS patched, what the hole was. Then they try to come up with a good exploit that takes advantage of that hole, then they start sending out the exploit, trying to hack machines and make bot-nets.

      Sometimes figuring out what exactly the hole was is tough. Sometimes figuring out how to make a usable exploit is tough. But sometimes it's not tough and it's all done, and the exploit goes wild within 24 hours after the release of the patch.

      If Lardtech sits on their ass, not even beginning the testing of that patch until the end of the month, they are gonna get owned big-time. Therefore, they don't want the bad guys to get it before their own internal guys can get it and start up the testing cycle, to minimize or eliminate the amount of time that an exploit is out there, and their own machines are unpatched. That's why they want a monthly patch date, in addition to what I already noted in my other post about not wanting to test each patch separately.

    2. Re:Why is this M$ problem??? by nlinecomputers · · Score: 1

      Well I see you point, to a point. If lardtech needs the time to test then how are they going to be fast enough to react no matter when the patch is released? It might take two weeks for them to test and roll out an update. This is the era of the zero day exploit. How is this any better? Sure they might be unlucky and have a patch come out on the 1st and they wait until the 31st to begin to roll it out. Or they might get the patch on the 28th and still get screwed over by a zero-day event.

      One wonders if it might be better if large companies got advanced secret issues of the patch, but then who can keep a secret eh?

      --
      Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
    3. Re:Why is this M$ problem??? by LurkerXXX · · Score: 1

      I believe you missed this bit of my post: "to minimize or eliminate the amount of time that an exploit is out there, and their own machines are unpatched."

      No one, even you at home, are going to be proof against a zero day exploit. It's not about totally eliminating all risk. It's about minimizing it. If there is a reasonable way to reduce the window of vulnerability, they'll take it.

      Getting the patch and beginning testing on it the same day the hackers get it is much better than letting the hackers play with it for a good chunk of a month before you even begin testing.

      Now the monthly release cycle does benefit the large corps and does hurt home users a bit. I don't know if the pluses of the monthly releases really outweigh the minuses. There are lots of variables and I don't know all the numbers. It may not be the best way, but the big corps do have some valid reasons for wanting it the way it is.

  60. Deadlines by homebrandcola · · Score: 1

    I work for an IT department for a very large organisation. The worst thing about having all these patches released on the one day is that everything else grinds to a halt while we go through the patches and prepare them for release. Even if we have deadlines on the Thursday (Tuesday is Wednesday here), everything else stops for the patches.

    It would make everyone's life here a lot easier if there were a couple of patches a week and we could spread that workload out and continue with other work.

  61. Re:How about they stop changing my default browser by SEMW · · Score: 1

    FFS, it doesn't change your default browser. There is a KNOWN bug in Firefox (since version 2.0.0.2) that makes it think it's not the default browser, when it actually is. The fact that it remains the default browser is easily verified by opening a URL or HTML file: it still opens in Firefox.

    For more information, see http://www.zoliblog.com/blog/_archives/2007/3/26/2 836828.html

    --
    What's purple and commutes? An Abelian grape.
  62. Re:How about they stop changing my default browser by rsmoody · · Score: 1

    Well, shit on me. Didn't know that, thought it was the evil Micro$oft. Dern, now I must apologize. NAH!!!!! Thanks for the info.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  63. Exploit Wednesday by Criffer · · Score: 1

    It's not "Patch Tuesday", it's "Exploit Wednesday".

    Release your exploit in the wild the day after the second Tuesday of the month, knowing that there will be nothing to stop you for an entire month!

    Why start an attack on any other day?

  64. Re:End Patch Tuesday by IchBinEinPenguin · · Score: 1

    Every other day I have a little star on my desktop notifying me of updates to various libraries, applications, and yes the kernel itself.

    There's your answer: your distotr (ubuntu?) patches _everything_ you have, from the kernel to your desktop theme (using the same simple mechanism!). No wonder there's a patch every couple of days.

    Microsoft only patches your kernel, window manager, web browser, email client and a few apps (min hunter, solitaire ..). One patch a month sounds about right.
    Except there's one bundle of patches a month...

  65. Patching can break applications when by halr9000 · · Score: 1

    Patching can break applications when:

    • due to poor programming practices (perhaps Microsoft, equally or more likely third-party programmers), an application depends on a flaw in order to function as expected
    • a patch tightens permissions on a file or object (e.g. DCOM or ActiveX component)
    • an application checks for certain file versions or datestamps of a file that is patched
    • obviously, if there is a bug in the patch

    I'm sure there's other reasons.

    In my experience, it doesn't actually happen that often. But when it does--it's a huge frickin' deal to the customer with a down ecommerce or accounting system. Therefore (if you care about uptime), you have to treat your apps with kid gloves and test everything. Fact of life. And as an aside, I'm not sure why the article author thinks this is a Microsoft thing. Many companies try to stick to cycles like this. Some Unix vendors like to do it quarterly. It's a very practical thing to do. Once the number of systems you manage is higher than...ten, you (should be) are immediately looking for ways to automate and reduce workload. Having patches released on a perodic schedule is a very good way to help address this. Microsoft has this schedule because customers insisted on it, not because Microsoft just decided to do so. I was surprised it took so long actually.

  66. They wait till Tuesday to patch 0 day exploits too by WK2 · · Score: 0

    You just outlined everything good about patch Tuesday. Those are the reasons that companies asked for it in the first place. However, why does Microsoft wait until Tuesday to patch 0 day exploits too? Hackers wouldn't reverse engineer those patches, because the details are available online in a more clear format.

    --
    Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
  67. Re:End Patch Tuesday by businessnerd · · Score: 1

    Yes you are correct, I am using ubuntu (most of the time) and it is patching everything from the kernel to my instant messenger. This certainly accounts for the frequency. However, my original point is not that Linux needs patching just as often as Windows. My point is that Linux is not some magical "patch-free" operating system as the original poster was trying to imply.

    --
    "It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson