Saturday, August 14, 2004.
The Windows XP/SP2 FirewallThere is an old French proverb that admonests people to "not look the teeth of a given horse". It might not be the stallion you want to ride into battle, but a horse is a horse, and if it has no obvious defects polite people are supposed to say thanks. So, when Microsoft gives away a pretty good firewall in the service pack 2 of Windows XP, you might think that people would be mostly pleased. In truth, most people are pleased, including many security experts. But then, there is the inevitable criticism, that the firewall might not be secure enough, that it may even give users "a false sense of security". Ouch. Most of the criticism centers around two points: that the firewall does not block outgoing connections, that applications can turn it off.
Let's start with the issue of incoming and outgoing connections. From a security point of view, there is a lot of difference between the two. An outgoing connection occurs when the user decides to fetch information on the Internet, for example to read a web page or to go fetch the daily e-mail batch. The owner of the computer, or at least a local program acting on the owner's behalf, decides when to issue these connections, which web site or server to contact, and what kind of message should be sent to these servers. In contrast, an incoming connection occurs when a third party, somewhere on the Internet, decides to contact the local computer. The user has no control over who that third party is, when it will decide to initiate a connection, of what type of message it will send. It may be a good buddy initiating a connection to your intant messaging program in order to exchange the pictures of last year's vacation. It may also be a virus that selected your Internet address at random and is trying to overtake your defenses. In fact, this is exactly how worms like Slammer, Blaster or Sasser propagated over the Internet.
If we block incoming connections by default, we reduce the "surface of attack" that the computer presents to worms like Slammer or Blaster. If we close everything, the surface is null, and we have entirely blocked an avenue of attacks. Obviously, we cannot always close everything. Users want to exchange files with each other, establish voice and video calls, play video games. Each of these application may have a bug, which may be exploited by a virus some day. So, we will have a way to "open up", to allow some applications to listen to incoming connections. The important point is that the user can control which applications listen to the network, and that is exactly what the firewall enables.
Once we have accepted that some applications will be enabled, we have to decide which ones. We quickly ruled out the idea of shipping a list of applications that would be "authorized by default". Imagine the howling if the list had included Windows Media Player and omitted its competitors! And then, imagine the state of the firewall if the list had included every product that somehow competes with another product already in the list! So, there is no default list, which means that applications have to be authorized one by one. At that stage, our main design constraint was to balance security and ease of use. The security objective can be summarized with four simple principles:
It turns out that application developers are quite protective of what they call "the user experience". We saw all kinds of abuses in early instantiation of the firewall, as creative programmers developed "firewall avoidance" and "pop up avoidance" strategies. Some applications will ask for opening a range of port number during their installation procedure, to be sure that the specific port that they will use will not be blocked -- never mind that doing so would also open the firewall for a gaggle of other applications. Others would spawn a management script that would open the ports in the background. Yet other explained us that it is technically possible for an application to send a message to a pop-up window, and effectively say yes on behalf of the user. So, we settled for some kind of "honor code": applications can ask the firewall to be placed on the "exception list", but should only do so after effectively asking the user for permission.
There is an obvious problem with honor codes: the bad guys have a tendency to not honor them. This is the crux of the argument against letting applications "authorize themselves". So, if the computer has been somehow infected, the "bad" application could open a hole in the firewall. Well, yes, but then it could also just turn off the firewall altogether, or it could use any of the "pop-up avoidance" strategies mentioned above. We have to assume that the worm writers have a copy of our software, and plenty of time. If there is a way to turn off the firewall, they will find it. There has to be a way, since we want to give users the possibility to replace our firewall by a commercial product of their own choosing. So, we decide to not concentrate on the bad applications, and rather ensure that the good applications can run easily. For us, the main risk is not that a worm turns off the firewall. The main risk is that the user gets exasperated because an application does not run well, turns off the firewall, and now gets infected by a worm!
This same reasoning applies to the control of outgoing connections. Since we cannot have any kind of pre-compiled list of "known-good" applications, the user would have to authorize them one by one, which is guaranteed to be quite obnoxious. The resulting security posture would probably be worse, since most users do not understand the difference between incoming and outgoing connections. They will say yes when asked whether Internet Explorer may connect to the Internet, they will say yes when asked whether Outlook may connect to the Internet, and they will also say yes when ask whether the file sharing service should accept connections from the Internet!
Another issue with outgoing connection control is application identification. Clearly, we would like to prevent spyware from sending reports to their spy-server. But a lot of the spyware tends to run in the context of another application, as a browser web object plugged into Internet Exporer or as a Winsock Layered Service Provider loaded indiscriminately by all Internet facing applications. Since the browser and the mail client will obviously be authorized, controlling outgoing connection would not even control spyware!
In summary, I believe that the Windows Firewall shipping in XP/SP2 is a very good tool. It is simple, because, frankly, we did not want to write millions of lines of code and risk adding a security bug in a component that listens to the network all the time. It protects from incoming connections, and by doing so drastically reduces the "attack surface" exposed to worms and hackers. It is designed for ease of use, because we want users to actually use it, not turn it off. And if some people feel like buy a more sophisticated product, I will still be happy, because they too will be protected from the next worm!