Slashdot Mirror
Last Words On Service Pack 2
thejoelpatrol writes "So did Slashdotters call this one? Windows XP SP2 seems not to be so secure after all. A Register reporter goes in depth to find out just how safe a fresh install is. He provides a list of which dangerous ports are left open and which services are left on by default. I guess now we know why Microsoft's security timetable is 10 years." Reader ack154 writes "ZDNet is reporting that many Dell Inspiron users are reporting an extreme performance decrease since installing Windows XP SP2 - decreases as much as from 2.6ghz down to 300mhz. Dell claims no responsibility, claiming it is 'externally loaded software' and they don't support it. In the mean time there has been a fix posted on Dell's forums, which rolls back the processor driver." Finally, Marxist Hacker 42 writes "Amid complaints of too much XP Service Pack 2 coverage on ZD Net, David Berlind writes that Service Pack 2 deserved the scrutiny it got- and charges that it failed to live up to Gates' Trusted Computing Initiative." Finally, Microsoft warns that installing SP2 on a spyware-infested PC is a bad idea.
This is why I didn't bother. My XP Pro with SP1 is protected with a firewall, updated virus scanner and Spybot S&D's innoculator. Running Firefox and Thunderbird and anti-spam software doesn't hurt as well.
I might add that the free/OSS I have protecting my machine weighs in considerably less in terms of combined file size then does SP2.
You want to know who isn't running Firefox 2.x? They spell it "definately" and "rediculous".
I haven't had ANY decrease in performance. I have had a lot more stability with wireless networking now though.
Yes, perhaps there are things that could have been done better in SP2, but the simple act of filtering inbound connections is a massive step forward in security for Windows users.
I say it's a "massive step forward" because there are literally MILLIONS of windows machines which are never updated, don't run any firewall software, and which are directly connected to broadband ISPs. The people running these boxes truthfully don't know what they're doing in these matters.
Right now, those poeple have NOTHING. Now at least they will have something, albeit limited. This is a major improvement. Even the old XP internet connection firewall, if it had only been enabled by default, would have prevented Blaster from ever happening.
Of course there are some questionable exceptions in the new firewall default configuration, and no doubt the next generation of worms will take advantage of those - but at least the bar has been raised a little higher.
Think about it, for a moment. The firewall is blocking internally-generated connections. Which is fair enough. (Though silently dropping would likely have been safer.) However, to lock the machine up, the TCP stack has got to be taking the error as cause to retransmit the packet.
Why am I so certain that this is what's happening? Because Windows has had some degree of preemption for a while. It's not great, but it works. Sort-of. Lock-ups should be next to impossible on a totally pre-emptive OS, as the locked-up program would simply be interrupted. It'd slow the machine down, slightly, but it wouldn't be fatal.
What we're getting here, though, looks like something fouling up big-time in a non-blockable part of Windows. Odds are pretty good that it's the network code. My suspicion is that the TCP stack and firewall are in an unbreakable infinite loop, with the error generated by the firewall causing the TCP code to resend the packet, ad infinitum.
A lot of people have argued that Microsoft isn't to blame for other people's crappy code. Which is fair enough. But they are very much to blame for their own crappy code. If you're going to have non-blockable code (a VERY bad idea!) then you've got to be damn sure that there are no scenarios in which that code will put itself into a spin-dry cycle.
It seems as though Microsoft merely added firewall code, with absolutely no thought as to the possible impact it could have on the rest of Windows.
Further, if my suspicion is correct (and I'm pretty confident it is), then it should be possible to crash any Windows box remotely. Simply generate a packet that Windows cannot reply to. By forcing the TCP stack and the firewall to fight it out, you'd paralyze the machine.
The correct way to handle this kind of situation is to recognise when a connection is administratively prohibited or impossible, and to not keep retrying. You'd then escape out of the non-blockable code, and pre-emption would allow you to continue as normal.
If you want slightly "smarter" behaviour, then if a process repeatedly keeps retrying a connection or activity that is prohibited, every time it gets woken back up, it should drop in priority, be slept a reasonably long time (in the hope the problem can be cleared by then) or get kicked off the system. ("Three strikes and you're out." logic.)
It should absolutely not be possible for any user process, no matter how badly written, to create a situation in which an uninterruptable infinite loop can develop. Either there needs to be some mechanism to interrupt any loop that might be infinite, OR there needs to be a mechanism for recognising when a loop is running unacceptably long.
It's no use Microsoft whining that customers should clean their computers first. That would be like McAffee arguing that you should clean your computer of viruses before running their software. And how are you supposed to do that, if you've no software installed for detecting and/or cleaning the damn things in the first place?
The only way you can know (for certain) that there's nothing trying to access an unauthorised port is by blocking the ports and seeing what happens when you try to use the computer as normal. And the only way you can then do anything about it is if the computer can cope with that situation in a controlled manner.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)