|The Death of TCP/IP|
Why the Age of Internet Innocence is Over
By Robert X. Cringely
As events of the last several weeks have shown, Microsoft Windows, e-mail and the Internet create the perfect breeding ground for virus attacks. They don't even have to exploit Windows flaws to be effective. Any Visual BASIC programmer with a good understanding of how Windows works can write a virus. All that is needed is a cleverly titled file attachment payload, and almost anyone can be induced to open it, spreading the contagion. It is too darned easy to create these programs that can do billions in damage. The only sure way to fix the problem is to re-stripe the playing field, to change the game to one with all new rules. Some might argue that such a rule change calls for the elimination of Microsoft software, but that simply isn't likely to happen. It's true that Linux and Apache are generally safer than Windows 2000 and IIS, but Microsoft products aren't going to go away. I promised you an answer to how to secure the Internet, and I mean to come through. First, we'll start with the way I would do it, then follow with a rumor I have heard about one way Microsoft might want to do it.
The wonder of all these Internet security problems is that they are continually labeled as "e-mail viruses" or "Internet worms," rather than the more correct designation of "Windows viruses" or "Microsoft Outlook viruses." It is to the credit of the Microsoft public relations team that Redmond has somehow escaped blame, because nearly all the data security problems of recent years have been Windows-specific, taking advantage of the glaring security loopholes that exist in these Microsoft products. If it were not for Microsoft's carefully worded user license agreement, which holds the company blameless for absolutely anything, they would probably have been awash in class action lawsuits by now.
Of course, it is not as though Microsoft intended things to be this way. No company deliberately designs bad products. But you must understand that Microsoft limits its investments to things that will enhance a product's market share. Every feature in Windows had to pass the litmus test, "Does it increase market share?" Putting security safeguards in their products evidently failed the litmus test, and therefore weren't added. While it is true that virus authors will target platforms that give them the most bang for their programming buck, the Windows platform has virtually no security to even slow them down. I believe the lack of security in Microsoft software was a deliberate business decision.
Alas, things are only likely to get worse in the near term. So far, we've been lucky in that most virus authors have been impatient and want to see the immediate effects of their work. It is far more effective to be patient and let the virus spread quietly for months. If the virus does nothing, the defense against it will be slow and/or too late. If the virus does very little on one's PC (for awhile), it won't be discovered easily. It is also possible to make a stealth virus. I won't go into specifics for obvious reasons, but if you think about how virus detection software works, it isn't hard to trip it up.
Even if 98 percent of the world's computers had current anti-virus software (which they don't), the remaining two percent would still be millions of devices capable of bringing down the entire Internet if infected.
And now, we have the impending release of Windows XP, and its problem of raw TCP/IP socket exposure. As I detailed two weeks ago, XP is the first home version of Windows to allow complete access to TCP/IP sockets, which can be exploited by viruses to do all sorts of damage. Windows XP uses essentially the same TCP/IP software as Windows 2000, except that XP lacks 2000's higher-level security features. In order to be backward compatible with applications written for Windows 95, 98, and ME, Windows XP allows any application full access to raw sockets.
This is dangerous.
Not only is it dangerous, it is unnecessary. What is wrong with telling application developers, "Your application can't have access to raw sockets," or, "When XP ships you need to have a non-raw socket version ready for your customers," or, "If your application needs to access raw sockets, these are the security rules and interfaces you will have to use"? The bottom line is that Microsoft's choice to provide access to raw sockets was based on the market share litmus test, period.
Unless this feature is changed before XP is released, it will mean that millions of new computers will be manufactured as perfect little virus machines. Virus authors who are anticipating these new PCs will be able to pre-position their digital vermin to take advantage of the socket flaw as the new machines appear. The result is that, in all likelihood, there will be massive data security problems, as well as massive damage to files and property, all as a result of Windows XP.
But as consumers, guess what -- we won't even get a choice. Microsoft will require the PC makers to install XP in the factory. It will come on your PC, and you won't have the choice or option to pick something different. When Microsoft issues a new OS, it is forced into the market.
Here is my preferred solution for Internet security. We could implement a secure user identity system precisely like telephone Caller ID. It would be essentially an Internet ID. All Internet transactions could be based on it. Anyone who sends me e-mail can be identified. Anything I send can be traced to me. People wouldn't be forced to participate, but if they remain anonymous, I might choose to block them. I certainly wouldn't accept file attachments from them. I know you hate this idea, but I think the Internet needs a fingerprint. It does not have to have personal information, but if you break the law it can be traced to you. You can choose not to have a fingerprint, but then your ability to communicate with others may be limited -- a price many people may choose to pay.
I am not opposed to people being anonymous -- just to anonymous people receiving public assistance. Send all the anonymous love or hate mail you like, but don't expect to attach a file.
And what's with those file attachments, anyway? Replace mail clients and APIs with secure models. The new model will not run attachments as they do today. E-mail attachments should not have access to the e-mail client, APIs, etc. Attachments should not have access to the operating system by default. The user should approve the use of some APIs, like having to give permission before device drivers are updated.
Any application that wants to send bits onto the Internet must first be permitted to do so. Applications would be registered to send outgoing traffic. The applications would be limited by function and port. You would register your e-mail program as the only application that could talk SMTP, POP3, etc. If Microsoft Word wanted to send an e-mail, your e-mail program would pop up, ask you to authenticate yourself and explicitly send the message. At that point, you would be in complete control of what was happening on your PC. For mail-enabled applications, there would be an application user account registered on the post office. The account would be unique, and registered to a unique application.
If kids want to install an Internet game, the game's IP port would be registered and permitted to operate, hopefully by the parent. If kids wanted to install an Internet chat program, too bad -- it wouldn't work if Dad didn't want it to work.
By default, under this scenario, your PC becomes a TCP/IP read-only device. By running applications like Gibson's Zone Alarm you can -- right now -- severely limit the use of TCP/IP by applications on your PC. And what happens when you do so? Everything works just fine. So rather than ripping the protocol stack wide open, let's do the exact opposite. Restrict access to it.
The only e-mail activity on my PC should be initiated by me, personally. Nothing else should access my address book or send out messages without my express permission. Microsoft will of course reject the idea, mostly because it will fail the "increase market share litmus test." My answer is, "Microsoft, if you do not take responsibility for locking down your APIs, it will become obvious to the public and become a detriment to your market share."
Now to the other approach, the one some people attribute to Microsoft. I am not making this up. The story came to me from people I have come to trust, and I have looked into it closely enough to think it might have some validity. But for the sake of keeping lawyers off my back, let's just call it a rumor, and only use it as a basis for discussion. To be perfectly clear, I am not claiming that the following is true -- just that I have heard it from more than one source, and think it accurately characterizes some past behaviors of Microsoft. Perhaps by bringing it into the light, we can ensure that Redmond takes a more thoughtful course. I certainly hope it is wrong.
Programmers who ought to be familiar with Microsoft's plans have suggested that the real motive for raw socket support is for Microsoft to use Windows XP to exploit a bad situation, to deliberately make things worse.
According to these programmers, Microsoft wants to replace TCP/IP with a proprietary protocol -- a protocol owned by Microsoft -- that it will tout as being more secure. Actually, the new protocol would likely be TCP/IP with some of the reserved fields used as pointers to proprietary extensions, quite similar to Vines IP, if you remember that product from Banyan Systems. I'll call it TCP/MS.
How do you push for the acceptance of a new protocol? First, make the old one unworkable by placing millions of exploitable TCP/IP stacks out on the Net, ready-to-use by any teenage sociopath. When the Net slows or crashes, the blame would not be assigned to Microsoft. Then ship the new protocol with every new copy of Windows, and install it with every Windows Update over the Internet. Zero to 100 million copies could happen in less than a year, and that year could be prior to the new protocol even being announced. It could be shipping right now.
Suppose you are a typical firm that also has some non-Microsoft servers. You will want to use this new protocol between your Microsoft and non-Microsoft servers. Microsoft could charge Sun millions to put TCP/MS on their systems. Microsoft can promise open support, but make it financially impractical. Then use it in a marketing attack against competitors. Zero-Footprint network drivers, ODBC, and MAPI are examples of Microsoft "open" standards that took years for non-Microsoft firms to use. Almost anyone who would have wanted to use these open standards has been driven out of business.
Second part of the push for the new protocol will be from AOL/Time-Warner, normally Microsoft's top competitor -- but not on this issue. AOL isn't really part of the grand vision of the new protocol. It's just that if they get more of what they want (paid accounts, music and video royalties), they won't object to Microsoft pushing for secure authenticated connections.
Third and most powerful part of the push for Microsoft's new protocol will be action by Congress. They'll cite concerns of business, and hold up the standard scare tactics of terrorists and child pornographers. They want all connections, all packets to be traceable.
Say goodbye to TCP/IP and to anonymous connections of any kind. Hello to Hailstorm, tracking everything down to the last mile, and a more business-friendly Internet with prioritized packet-handling.
If this seems like too much infrastructure to change, it isn't. Not if the old protocol has been rendered useless and the new one can be implemented by an upgrade to your router. Vines IP -- in many ways the basis for TCP/MS -- was sufficiently close to regular TCP/IP that most routers only had to have a flash upgrade (to IOS, in the case of Cisco) in order to route Vines IP. This will be an inconvenience, sure, but marketing types will see it more like another Y2K bug -- an opportunity to sell, sell, sell.
But won't the Internet Engineering Task Force (IETF) stop it from happening? No. The entire basis for setting standards on the Internet is to first put the new code in service, and then seek standardization. There are no IETF rules that say 100 million plus computers can't run TCP/MS, and there is no deadline for standardization. Once the right 100 million plus computers are running the new protocol, Microsoft won't have any reason to seek standardization. Why not? It is Possible, for awhile, to run more than one protocol at a time. Take as examples of the coexistence of IPX and IP in Netware systems, or AppleTalk and IP in MacOS systems. Business will push for the new protocol, and the result will be that TCP/MS will become a de facto standard, and Microsoft will own the Net.
And all you have to do to kick it off is implement raw socket support in the next shipping version of Windows, with the possible bonus of blaming any problems on UNIX code later.
If business feels a need for the ability to have prioritized packet Delivery, and government (plus the Recording Industry Association of America) is uncomfortable with the notion of untraceable packets and connections, of course Microsoft is going to try to fill that niche. Haven't you noticed how their ads have been trying to convince people that Microsoft software is amazingly stable and secure, and doesn't need minding? That's the image they're trying to build -- solid as a bank.
MS/TCP will ostensibly be a solution to the problems businesses are having with the Internet. It will assign priorities to packets. It will insure that all connections and packets can be traced, authenticated, and monitored. And since all these connections to the Internet have to be authenticated to someone, it will likely be hooked into a credit card or some sort of account, from which Microsoft can extract its price as the gatekeeper for the authentication via Hailstorm, Passport and .NET.
But how will this stop the "I just e-mailed you a virus" problem? How does this stop my personal information being sucked out of my PC via cookies? It won't. Solving those particular problems is not the protocol's real purpose, which is to increase Microsoft's market share. It is a marketing concept that will be sold as the solution to a problem. It won't really work.