Microsoft Confirms Update-Linked BSODs Required Compromised Machines 199
Trailrunner7 writes "Microsoft on Thursday confirmed that the blue screen of death issues that affected a slew of users after the latest batch of Patch Tuesday updates is the result of an existing infection by the Alureon rootkit. There was widespread speculation after the patch release that simply installing the MS10-015 update was causing the BSOD condition on some Windows 32-bit machines. However, Microsoft said at the time this was not the case and started an investigation into the problem. In an advisory released Thursday, the company said that it now was confident that the restart problem is being caused by the Alureon rootkit." That seems a harsh way to find out that your Windows machine has been rooted.
Most effective mechanism for making a safer 'net (Score:5, Interesting)
Re:Better than not knowing that you've been rooted (Score:2, Interesting)
Couldn't a deep packet inspection reveal the botnet behaviors regardless of how good the rootkit was?
Sounds like a home router feature to me...
Re:Dumbass users.. (Score:5, Interesting)
48 hours ago I was notified of a laptop with a rootkit.
And I can tell you now, that laptop wasn't running slowly.
It wasn't redirecting web requests.
It wasn't doing any of the things you might associate with rootkits. Yet replacing the AV with an alternate product and the alternate product detected several real issues.
Frankly, if I hadn't been notified by our bank (whose security company had managed to get a site shutdown and get a list of all potentially compromised accounts) I would never have had a clue. I concede that the user had admin privs on their laptop but I'm given to understand that even that isn't a huge barrier to a lot of modern rootkits. Thank Christ the bank in question doesn't allow you to do anything without the use of a separate security device they ship you.
Talk about a rock and a hard place. I can't trust the laptop at all, and it was infected while running a regularly-updated copy of Symantec AV Enterprise which suggests I can't necessarily rely on AV software to do what it says on the tin. Windows is obviously a lost cause unless I want to spend the rest of my live playing whack-a-mole yet I don't think the Powers that Be will stomach a move to Linux (even though most of them haven't used Windows-specific software in years).
Answers on the back of a postcard....
Re:But better than not finding out at all. (Score:4, Interesting)
When the rootkit has complete, unrestricted access to the system, *it can do anything it wants*. there really isn't a way to stop it, unless you've forced it into a lower-security prison (aka, user-level).
If it wants to pick a random memory address that it's hard coded and jump to it, it can do it. the cpu's not going to stop it, and windows is not responsible for fixing that. You may as well ask for the linux kernel to stop a rootkit module from rewriting the software interrupt vector tables and hooking into system calls. If it has write-anywhere memory level access (and it does, it's in the kernel during initialization, launched by root), then it can write bytes to memory, anywhere it chooses. if you then upgrade to a kernel with a different system call table layout due to an improvement, and the malware doesn't self-correct? boom!
Now, solutions to this involve things like virtualization and sandboxing, but we're not quite there yet. I wouldn't actually mind seeing an operating system take advantage of VT and other things to produce an OS with a secure core, that self-verifies and only accepts signed updates.
The network doesn't lie... (Score:3, Interesting)
Re:But better than not finding out at all. (Score:3, Interesting)
Well, you can do some forensics first if you want, and maybe copy off some data (if you're careful about how you do it so as not to infect any system you copy it to). But you're going to boot from known-clean (and, preferably, read-only) media to do those things, NOT from the known-infected system. (A LiveCD is what I would recommend for such post-mortem activities.) If you want to actually boot from and use the infected system again, it needs a clean reinstall first, period. Do not pass go, do not collect two hundred dollars. Booting from the infected system is highly inadvisable and much worse than useless, because the system is compromised. Only someone who doesn't know any better due to a complete lack of understanding of security issues would even consider doing that.
So personally I don't see how this way of finding out is any more brutal than any other way of finding out. Continuing to use the system, even though it has a rootkit, wouldn't be a reasonable course of action anyway. Nobody who understands security would do that, and nobody else *should* either.
(Unless you're operating some kind of firewalled-garden virtualized honeypot network for the express purpose of studying how infections spread, but in that case you wouldn't be deploying the patch. I suppose if you were doing a controlled study on the effectiveness of the patch... but we're now DEEP into the realm of purely hypothetical problems with no real-world impact whatsoever.)
If we were going to criticize Microsoft here, it would be for other things, such as how long it took them to deliver the patch once the issue was reported. (I don't happen to know how long it was in this instance, BTW; I wasn't following this particular vulnerability very closely.)
Assuming it's true that the patch only causes problems on already-rootkitted systems (and I haven't seen anyone claim the contrary), then that's not really a meaningful flaw in the patch, IMO. Those systems were already toast anyway. How well does the patch work on systems that hadn't been infected? That's what matters.
Re:But better than not finding out at all. (Score:1, Interesting)
race condition, I guess - if you do the malware removal first, then there will be a window of opportunity to get reinfected by the same flaw until the updates apply.
Just a guess, though.