Gibson 1, Microsoft 0 (background info)

Rob Rosenberger, Vmyths co-founder
Wednesday, 8 September 2004 [Editor's note: it will help if you first read the main part of this series.]

I WANT YOU to think of every Dracula movie you've ever seen. (No no, hear me out...) You can slay Dracula's minions, of course, but Dracula can just bite more minions into existence. On the other hand, if you kill Dracula, all of his minions die instantly with him. Just about every Dracula movie ends this way. Try to visualize each of Dracula's minions as a symptom of the real problem — Dracula himself.

"What's the sense of providing a ninety-percent implementation of commonly-used networking functions? The only thing you do is force people to write the last ten percent themselves or go out and buy a piece of third-party software that implements the last ten percent."

Okay, now I want you to think of a poorly configured router as Dracula and a thousand "zombie" PCs as minions who abuse raw sockets to create evil packets. It makes sense to stop evil packets at the router, not at the OS. But Microsoft crippled an OS in the quest to slay some of Dracula's minions. They wrote a security patch to stop some zombie PCs from sending out undesirable packets. Security celebrity Steve Gibson blew his top when Microsoft put the Berkeley sockets API in Windows XP. But why did Microsoft make this choice in the first place? Our story begins in the early 1990s before the Internet grew popular. Microsoft learned a valuable lesson with Windows 3.0 — they realized "even a little guy who writes software in his den room" can add immense functionality to any OS. The folks in Redmond shunned little guys while developing Windows 3.0 but actively courted them for Windows 3.1 and Windows 95. Those little guys helped make Windows a desktop monopoly. Microsoft users "surfed" on bulletin boards in the early days and they had plenty of software to get them connected. If you wanted to surf the Internet, though, you first needed to make Windows compatible with the Internet. Utilities like Trumpet Winsock gave Windows the networking interface it needed. Microsoft banged out a sockets API known as "WinSock 1.1" when the Internet exploded in popularity. Microsoft knew Internet software would add immense functionality to their OSs and they courted "the little guys" to compile products for the Windows platform. But the little guys often refused to do it, citing an incomplete networking interface (among other reasons). Microsoft security wonk Scott Culp pointed this out in 2001:

It makes sense to provide [support for raw sockets] at the OS level... From a rationality point of view, what's the sense of providing a ninety-percent implementation of commonly-used networking functions? The only thing you do is force people to write the last ten percent themselves or go out and buy a piece of third-party software that implements the last ten percent... I mean, we could do that. You've got a TCP stack that gives you ninety percent of what you need, and you've got to come up with the last ten percent or buy a third party product, and people would say, "what, are you nuts? Give me the last ten percent for crying out loud."

Microsoft implemented the full Berkeley sockets API in "WinSock 2.0" for Windows NT and Windows 2000. Gibson threw a series of temper tantrums when he learned the new Windows XP would include it, too. He launched a full-blown media crusade to cripple its default networking interface.
SERVICE PACK 2 removes "outbound support for raw sockets" from the default networking interface in a misguided attempt to solve symptoms. What did Microsoft give as a rationale for crippling an entrenched Internet specification? "We surveyed applications and found the only apps using this on XP were people writing attack tools."

Microsoft spiked Bill Gates' plan to unify their operating systems under a single code base. This means Gibson wielded more power at Microsoft than their chief software architect. With a flawed argument, no less!

Microsoft clearly didn't survey enough applications. When Service Pack 2 cripples the default networking interface, it cripples some very useful programs for computer security and network administration. Programmers who write primarily for the Windows platform can fix it with third-party software. Programmers who write for many OSs might add special code to handle Service Pack 2. Look at how the author of Nmap (a popular computer security utility) dealt with it:

Workaround crippled raw sockets on Microsoft Windows XP SP2 scans. I applied a patch ... which causes Nmap to default to winpcap sends instead. The winpcap send functionality was already there for versions of Windows such as NT and Win98 that never supported Raw Sockets in the first place.

And — get this! — evil Internet programmers will devise their own workarounds for a crippled default networking interface. To put it another way: Service Pack 2 doesn't truly slay Dracula's minions. Dracula can regain each of those minions with another bite to the neck! Microsoft shot itself in the foot, no doubt about it. First they switched to an entrenched specification so Internet programmers would compile products for the Windows platform. Then they lost sight of why they did it. They deviated from an entrenched specification to stop evil Internet programmers from using the default networking interface. When Microsoft caved in to Gibson's flawed thinking, they spiked Bill Gates' plan to unify their OSs under a single code base. Believe it, folks: Gibson wielded more power at Microsoft than their chief software architect and the Internet Engineering Task Force (IETF), combined. With a flawed argument, no less! Let's return to the question of who should protect the Internet from undesirable packets. As I said, the IETF places this burden on routers & hardware firewalls — at layer 3 to be precise — but Microsoft now volunteers to bear the burden at higher layers, if only via their default networking interface. I asked Theo de Raadt, the driving force behind OpenBSD, if other OSs will follow Microsoft's lead and disable outbound raw sockets for security reasons. He spat back:

In security, they [Microsoft] are not leading or even following. Their change is just appeasement for the masses to make it appear as if they are doing something worthwhile. It is placating the masses and the press. Their change does nothing. Any application that gains any of the easy to get privileges in Windows can still send any packet it wants. Trust me... Any protection method you believe to be there is simply a veil.

This, from a man who oversees arguably the most secure desktop OS you can install "right out of the box." Some people might interpret de Raadt's comments as a slam against Gibson's flawed thinking, but I view it as a slam against Microsoft's implementation of Gibson's flawed thinking. I paraphrase the Internet's new Security and Stability Advisory Committee when I say Microsoft's decision may have "violated fundamental Internet engineering principles by blurring the well-defined boundary between architectural layers... Thirty years of experience show that this strategy ensures robust engineering and engenders trust in the systems and the processes surrounding their maintenance and development."
I'VE SAID IT before and I'll say it again. Gibson's crusade has always been a router security issue, not an operating system security issue. Every legitimate router security analyst knows this. Microsoft would know it, too, if they wrote router software instead of OS software.

Gibson belatedly acknowledged the obvious to avoid ridicule, then he used a superset of reasons to solidify his position.

Many shallow thinkers use this defensive maneuver to protect their egos and Gibson is no exception here.

("Oh, and I suppose you are a router security analyst, Rob?" Yeah, back in 1996-97. Five years before Gibson mis-identified the need for router filtering. I was later invited to join a router security research project but I declined it for personal reasons.) Know this: proper egress filtering at the router solves all of Gibson's fears about raw sockets. Instantly. For every computer on the network. Regardless of the operating system it uses. Regardless of the security patches applied to it. Regardless if it's a zombie under Dracula's control. Gibson himself belatedly acknowledged this fact:

I believe that proponents of ISP network egress filtering are COMPLETELY correct... Today, the practice of network egress filtering is more the exception than the rule, but we can hope that it will be widely adopted as these issues attain increasing visibility in the future.

A savvy reader will notice I quoted Gibson's acknowledgement out of context. I can only quote him in context if I include the very next sentence of his acknowledgement — and that next sentence introduces one of the major flaws in Gibson's thinking:

However, this potential for an improvement in the Internet's infrastructure notwithstanding, it is important to recognize that ... Egress filtering does NOT solve the whole problem.

I repeat: proper egress filtering solves all of Gibson's fears about raw sockets. He may be a security celebrity, but his shallow conceptualization of the problem tells us he is not a legitimate router security analyst. Gibson then goes on to describe a larger problem. Many shallow thinkers use this defensive maneuver to protect their egos and Gibson is no exception here. He belatedly acknowledges the obvious to avoid ridicule, then he uses a superset of reasons to solidify his position. "Waitaminit, Rob," you interject. "You can fix the problems Gibson describes if you disallow raw sockets." It's still a router security issue, not an operating system security issue, and the Internet places a burden on layer 3 devices to stop undesirable packets. I want you to go back and look at the asterisk in the first diagram of Gibson's "raw sockets" tirade. Then look for the green text below it. I'll lead you to one of the flaws in his argument. According to the entrenched specification, any program run by an administrator may do anything with the sockets API. Home users overwhelmingly demand full administrator control from the time they logon until the time they logoff. Gibson doesn't even want to preserve raw sockets for the administrator — he wants to eliminate it, period. He wants to rewrite an entrenched Internet specification dating back to the early 1980s. "Hang on, Rob," you interject again. "Doctors will treat a patient's symptoms until they identify the problem. Gibson is treating symptoms just like a doctor would. What's wrong with that?" Well, for starters, Gibson's not an Internet doctor (but he plays one on G4TTV) and he made a quack diagnosis...
LONGTIME READERS WILL recall what I said years ago. Even if Gibson could magically wish Windows out of existence, its replacement would include a robust networking interface and home users would overwhelmingly demand full administrator control from the time they logon until the time they logoff. Gibson shouldn't scream at Microsoft for following an entrenched Internet specification — he should pester the IETF to revise the specification. Ah, but guess what? We know what the IETF would say to Gibson! "We've already identified the root solution. It's a router security issue, not an operating system security issue." I believe Microsoft snatched defeat from the jaws of victory when they caved in to Gibson's flawed thinking. Enough said.