Slashdot Mirror


McAfee Retracts Lowball Bug Damage Estimate

bennyboy64 writes "McAfee has changed its official response [warning: interstitial] on how many enterprise customers were affected by a bug that caused havoc on computers globally. It originally stated the bug affected 'less than half of 1 per cent' of enterprise customers. Now McAfee's blog states it was a 'small percentage' of enterprise customers. ZDNet is running a poll and opinion piece on whether McAfee should compensate customers. ZDNet notes a supermarket giant in Australia that had to close down its stores as they were affected by the bug, causing a loss of thousands of dollars."

4 of 233 comments (clear)

  1. what it did to my 11'000 computers by Atreide · · Score: 3, Informative

    we have 11K computers

    only XP SP3 computers were impacted
    whether running Virus Scan 8.7 or 8.5

    but in fact less than 100 computers were impacted,
    1% compared to our total

    one thing that helped
    was employees had started to leave after work when update propagated
    and they shutdown computer when they leave

    it could have been a nightmare
    we were very lucky

    --
    The world belongs to those who get up early. - I'm far from being the king of Earth then :-(
  2. Re:Getting real about things here by onyxruby · · Score: 4, Informative

    As a matter of fact I do expect that. I have designed and set up processes for patch management, software distribution and similar testing for large enterprise environments for years. I have done so everywhere from very large financial institutions to health-care and government. The fact that you need to test daily does not change any principal of what I have said. For any enterprise not to have a dedicated lab to do exactly this kind of testing, or ever worse, not to to use it is sheer and utter incompetence.

    In no case should an automated update for an environment ever be released into production without testing. Even Microsoft gets this point and allows you to disable automatic patching to ensure that proper testing can be conducted. I'm not trying to sound harsh, but in all seriousness if you can't learn why testing /every/ production change is necessary from this debacle, than you do not belong in enterprise management. It really is that simple.

  3. Not Windows' fault, but still its problem... by Animaether · · Score: 3, Informative

    ( Title after the VirtualDUB developer's excellent post entitled "Just because it is not your fault does not mean it is not your problem"; http://www.virtualdub.org/blog/pivot/entry.php?id=245 )

    Here's the thing.. it's not Windows' fault that some random program deletes svchost.exe , just as it isn't Windows' fault that any app or user can delete ntldr (e.g. a badly designed uninstaller).

    But it -is- a Windows problem because without those, it won't start up. So why is Windows even allowing these files to be deleted?
    I can't delete by hiberfil.sys even though all it is, is pre-allocated space for the hibernation functionality. If I deleted it, nothing would be lost, and upon hibernation it could re-allocate the required space or tell the user the drive is too full and they're SOL. But no - I simply can't delete it. But I -can- delete vital system files.

    So, no.. it's not Windows' fault that McAfee's virus scanner deleted the file. It -is- Windows' problem that they -can- in the first place.

    I realize that sometimes there may be a need for a 3rd party application to modify a system file - however rare - but then provide this through a proper mechanism that backs up the original and deletes/replaces on reboot only, with the option to deny the change on boot-up. ( System Restore points only go so far as you'll need the Windows CD/DVD in order to get to the restore utility if you can't boot into Windows anymore. It's also an overly complex solution to the simple problem of renaming files on bootup. )

  4. Sorry. PCI Rears its ugly head again. by knarfling · · Score: 4, Informative

    Even though it is Windows, there is absolutely no technical need for AV when the application is so limited.

    Fixed that. I am afraid that the Payment Card Industry (PCI) differs from your opinion.* In their infinite wisdom**, PCI has decreed that ALL computers need to be running AV. After, all, if it is good for the desktop, it must be good for the servers, right? And since a virus can be spread from anywhere to anywhere, all computers need to have their own protection.

    I know it seems silly, but many of the PCI Audit Drones actually believe this. I spent hours trying to convince an auditor that we did not need AV on a Linux server that cannot accept email and has no internet connection. If the PCI Audit Drone finds a computer without AV, you fail the PCI Audit. If you fail the Audit, you get marked as failing on a public web site. If you fail enough times, you lose your ability to accept credit cards. So the need to have AV on a POS is there, it is just not a technical need.

    *Reality
    **For very, very small values of infinite

    --
    Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.