Microsoft Windows XP sp2


 

 

 

 

 

Introduction to this web page

This web page contains some miscellaineous bits of information about Microsoft Windows XP service pack 2.

Much of it was written some months ago, but it wasn`t ever put on this website. I`ve now added some more comments following some recent observations. I hope that the original material is still valid.

 

Obtaining sp2

There are three ways of obtaining sp2 that I know of - there could be others, including ( I believe ) from magazine cover disks.

  • Download a 250 Mb file from the Microsoft website. Microsoft say this is the version you should use if you are going to roll out sp2 across an enterprise.

  • Use the Windows update service to download a 75 Mb version. Microsoft say this is the version you should use if you are just updating a single pc.

  • Obtain a CD, which Microsoft will send you, if you apply through their website.

 

Hard drive space

SP2 is very greedy on hard drive space. I used the Windows update service to install sp2 on two pc`s, and on both of them, the installation used up over 700 Mb of hard drive space. I used a cd version on another pc, and this installation used up 1 Gb of space. Sorry, I didn`t note how much space the 250 Mb version uses up.

 

Time for installation

The Windows update service is not famous for its speed - and sp2 follows the trend. The two pc`s took 75 minutes and 50 minutes ( 700 MHz and 1800MHz ). You can`t go away and leave them, as half way through you have to do some mouse clicking.

At home, XP estimated it was going to take about 4 hours via a dial-up connection. The cd version took about 25 minutes on a 400 MHz pc.

 

Raw sockets

sp2 has removed the capacity for applications to use raw sockets ( raw sockets is a mechanism which allows an application to access the networking layers without going through all the layers of the protocol stack ). So it does cause problems for some applications which need raw sockets.

 

Dynamic port allocation

As described on a previous web page, many operatings system use dynamic port allocation when instigating a network connection with a remote computer.

On Windows NT, the dynamic allocation starts around port 1025, and works its way upwards from there.

On Windows XP sp1, dynamic port allocation has two ranges - during boot-up, port numbers from 1025 upwards and from 3000 upwards are used. After boot-up is completed, then new connections use from port 3000 upwards.

However on XP sp2, this has changed - now, during boot-up, it only uses port 1025 upwards. Once boot-up is complete, it uses from roughly port 1047 upwards for new connections. This may have significance if a computer is connecting through a port blocking firewall and needs to use FTP.

 

The built-in firewall

SP2 has a more advanced built-in firewall than XP or XP + sp1. It is a stateful firewall, which means that it only allows in packets which are in response to packets sent out by an application running on the pc. Unsolicitated incoming connections are blocked.

There are no restrictions on outgoing connections.

You can program exceptions into the firewall, so that certain specified unsolicitated incoming connections are allowed. This can be done either by specifying a particular port and protocol, or by specifying an application which can receive unsolicated incoming connections.

There are several ways of programming in these exceptions that I know of :-

  • Use the GUI, which you can access via Control Panel / Security Centre / Manage security settings for / Windows firewall.

  • Use Group policies.

  • Use API`s. The firewall in sp2 has sufficient API`s that you should be able to programme in the full range of settings that you can apply through the GUI.

  • Use the Netsh command line environment. SP2 adds another netsh helper ( FWCFG.DLL ), so that the firewall can be configured via command line instructions. As far as I can see, the settings that can be made through the GUI can also be made through the netsh environment.

  • Manually add entries to the firewall .inf file. This is called "netfw.inf", and is located in the "inf" folder in the Windows root directory. The netfw.inf file contains settings which are put into the registry, however the syntax is different from normal . You can make the firewall reread the inf file by using the "netsh firewall reset" command. However this will remove all exceptions that the firewall has self-created. The netfw.inf file would be a good way to roll out a preset list of settings or exceptions to several pc`s.

  • Hack the registry - there are registry settings for the exceptions, and other configuration settings. So these can be added manually, or by using .reg files. For example, the following text in a .reg file would add port 5001 TCP as an exception for source addresses on the local subnet -

  •    Windows Registry Editor Version 5.00
    
         [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\....
    
           ....\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List]
    
         "5001:TCP"="5001:TCP:LocalSubNet:Enabled:5001-test"   

    It appears that you can`t add multiple ports via one registry entry, only one port can be added at a time.

 

Problems with the firewall

The firewall in sp2 does seem to present various problems, the ones I have found so far include :-

  • The default settings are different depending on whether sp2 has been installed on top of basic XP, or on top of XP sp1.

    When sp 2 is first installed on top of sp1, the firewall has two exceptions enabled, these are File and Printer sharing, and Remote Assistance. Both of these services allow and rely on external pc`s establishing unsolicitated incoming connections with the host pc, so it seems rather dangerous to have as a default that these are enabled.

    Enabling File and printer sharing through the firewall opens ports 137 UDP, 138 UDP, 139 TCP, and 445 TCP in the firewall. Ports 137, 138, 139 are used by NetBIOS, and are a favourite way of crackers attacking computers, and are also used by malicious applications that have been illicitly installed on a computer, to attack other computers. So even though the exception in the sp2 firewall for these ports is restricted to the local subnet, it still opens up the host pc to attack.

    The default exception for Remote Assistance through the firewall allows unsolicitated connections from the whole internet.

  • On the other hand, when sp2 is installed on top of basic XP, then the exception for File and Printer sharing is not enabled, but the exception for Remote Assistance is enabled, so the above comments for Remote Assistance still apply.

  • There is another inconsistency with the default settings - when sp2 is installed on top of sp1, as described above, File and Printer Sharing is enabled by default. However when the "Restore Defaults" button is selected on the GUI, or if the command line instruction " netsh firewall reset " is run, then File and Printer Sharing is not enabled as an exception.

    Remote Assistance is enabled as an exception in both cases.

  • Within the netsh command line environment, it doesn`t seem possible to see the scope of an exception - ie, to see what source ip address or addresses the exception is associated with. None of the show commands provide this information. The only way that I have found to see this information is via the GUI, by highlighting an exception, and going into edit mode.

  • Another problem with the netsh environment - it you make a typo, and try to run a command in which the syntax is not correct, then netsh responds with an error message. However if you run a command which has the correct syntax, but is trying to do something to the firewall that the firewall doesn`t like, then you don`t get any kind of error message, netsh returns the OK response, but the firewall ignores the instruction. There is no indication from netsh that this has happened.

  • Regarding the provision of API`s as a means of configuring the firewall, allowing applications to configure the firewall seems to be a bit controversial - whilst it is very handy for users to have their applications create their own exceptions, it presumably also means that malicious applications can also generate their own exceptions, and open the pc up to further attack.

  • It is not allowed to add a new rule for a specific port if a rule already exists with the same port number and protocol, even if you want to specify a different scope. You have to add the new scope to the existing port settings.

  • The firewall has a built in link between TCP port 445 and ICMP echo request packets. If you enable an exception through the firewall for TCP port 445, then it also enables an exception for ICMP echo request packets, and this can`t be disabled. ICMP echo request packets are a method used by attackers to attack computers, so it is desirable to be able to block these. However TCP port 445 is one of the ports that is set as an exception by enabling File and Printer Sharing through the firewall. As mentioned above, File and Printer Sharing is itself a dangerous service to have enabled through the firewall, so this is a double reason to block File and Printer Sharing through the firewall.

  • A further concern that I have about the firewall in sp 2 is that it doesn`t sit on the edge of XP, as a seperate programmable software unit. It is integrated within XP, and learns things from XP, and generates its own exceptions as it deems them to be required. As I said above, this is handy for users, but rather dangerous from a security point of view.

  • It looks as if most if not all configuration settings and exceptions for both applications and ports are stored as registry settings. This means that the security of the firewall itself is only as good as the security which can be provided for the registry. It isn`t particularily difficult for rogue websites to add stuff to the registry, so this is a problem. It perhaps emphasises the fundamental concept that a computer being used as a firewall should never be used for any other purpose, as other applications or services open back doors into the computer.

 


© 2005 Ron Turner


Return to the Index page