|E-mail Wes Simonds|
This summer has seen the emergence of a nasty little brouhaha between Steve Gibson (best known as a sometimes-outrageous...
Internet privacy/security expert) and Microsoft.
Gibson's case seems simple enough. Distributed denial of service (DDoS) attacks, already a serious and largely unsolved network security problem for companies great and small and the clients who depend on them, are about to get much worse as a result of Microsoft's network code in Windows XP.
Currently, one useful tactic for handling a DDoS strike involves looking for a recurring pattern in the incoming packets and leveraging it to filter those packets out. This in fact was Gibson's approach when his own site was the victim of a DDoS assault; the unwanted packets bore the IP addresses of the zombie computers used to send them. Once a key router was configured to discard packets from those addresses, the problem was, albeit imperfectly, solved.
With the advent of Windows XP, already sent to PC manufacturers and set to ship formally in October, that solution is going to vanish. For the first time, the leading consumer operating system will implement raw sockets, the specification of which allow for the creation of spoofed (or forged) IP addresses in outbound packets.
Why is the consumer aspect important? If you're a hacker looking to draft an army of DDoS slave machines, consumer computers are arguably ideal for the task. Consumers are easy to take advantage of: they're much more likely to fall prey to hostile code; they're much less technically aware of what their machines are doing in the background; they lack savvy network administrators, and yet, thanks to the wild success of cable modem/DSL deployments, they're also increasingly likely to have broadband connections.
Gibson says raw sockets are unnecessary for users, particularly Windows XP Home Edition users, and predicts, if not the actual end of the world, a notable increase in DDoS attacks as a result of the rollout of XP in its current state.
Microsoft has formally responded to Gibson's arguments. However, as we'll see, it has not done so as comprehensively or persuasively as might be hoped.
While I have considerable respect for Microsoft as a technology and marketing powerhouse, it appears to me that in the matter of security the company has once again gone to work wearing its underwear on its head.Here are the key arguments Microsoft makes:
1. "The presence of operating system-level functions to manipulate data packets is not a critical factor in the number of DDOS attacks. If it were, the explosion in DDOS attacks should have already occurred, as raw sockets implementations are already present in Linux, VMS, Unix, Mac OS X, and even in previous versions of Windows."
Hmm. This reasoning might follow if the worldwide consumer market share of all of these operating systems combined amounted to even five percent, but it doesn't.
And as we've seen, it's consumer machines that are most likely to be the major problem children in this matter.
2. "An attacker who had the ability to install zombie software on another user's machine could just as easily install a network driver to provide any functions it needed, including functions to disguise the source address of the attack."
This bit is considerably more logical, but still problematic. The fundamental question remains: Why should Microsoft save hackers the work of implementing spoofable packets on zombie machines?
What practical advantage, in other words, do consumers stand to gain by having raw sockets? What will they be able to do that they can't do today? Do consumers even know or care?
Which rabid host of consumers is it that's encamped outside of Microsoft's Redmond headquarters chanting war slogans, holding angry signs ("Current Sockets Insufficiently Raw!") and demanding the ability to spoof packets?
This is very unclear to me.
In the mid-nineties, Microsoft gave us new technology (an insufficiently secure macro-programming environment in Office) which led to the rise of the world's first cross-platform viruses (and a subsequent, incalculably vast loss of time, money and energy). Today's situation with raw sockets in a consumer OS seems similar to me: shiny new functionality, which is more likely to be abused than used.
3. "The real issue is whether the attacker could run hostile code on another user's computer. Like viruses, Trojan horses and other hostile code, a zombie program can only run if an attacker can install it and run it. Microsoft has embarked on a campaign known as the ?war on hostile code', with the goal of preventing any hostile code from running on users' systems."
No doubt Microsoft means well, and I applaud the implied initiative; however, the implementation falls sadly short of the ideal.
For instance, XP Home Edition will include a bundled firewall, the Internet Connection Firewall, but at this time it appears it will be incapable of filtering outbound packets (such as DDoS packets).
What Microsoft doesn't seem to realize is that incoming attacks are only half the issue. The other half is what the user will naively find and install, often without realizing it, which will lead directly to hostile outbound packets.
As any network administrator knows, the average user, particularly the average consumer user, is almost diabolically clever at finding new ways to install inappropriate and potentially problematic code. E-mail attachments, the best-known example, are only the beginning; there are alt.binaries.* newsgroups on USENET, there's the Web, there are peer to peer services such as Gnutella, there are Zip drives, and so forth ad infinitum. Leaving outbound packets unchecked on the assumption that the system is already secure is a recipe for disaster.
Those who have seen Star Wars may find this exchange illuminating:
Internet Connection Firewall: "Halt! Who goes there?"
Malicious DDoS code: "These are outbound packets. These are not the packets you're looking for."
Malicious DDoS code: (stares intently, using Jedi mind trick)
ICF (mesmerized): "Move along. Move along."
And while ICF snoozes, DDoS strikes will be launched.
FOR MORE INFORMATION
Contact Wes Simonds at firstname.lastname@example.org.