Last Updated: 2006-08-25 15:21:14 UTC
by Bojan Zdrnja (Version: 1)
Update: Intel is telling customers that a patch should be ready within 2 weeks (thanks Matthias).
Intel initially issued a big file (100MB) that you had to download, but at least it upgraded everything on your machine, if it needed upgrades.
After rebooting in the next few days I noticed that my machine is a bit slower then it was. A look at Task manager output, or excellent Process Explorer from Sysinternals showed that a process called S24EvMON.exe is using quite a bit of CPU, as you can see below.
That process gets started by the Intel(R) PROSet/Wireless Service, which is used to manage the wireless card.
After battling with this, and as I was going to a conference, I went to Dell's web site and noticed that they released their own version of drivers. Hoping that this will fix the problem, I downloaded another 90MB to find out that Dell's drivers have the same problem.
I initially thought that there is maybe something else on my machine causing this, but as news started spreading around, it looks that everyone with (at least) 2915ABG/2200BG wireless cards is affected. F-secure posted this in their weblog as well: http://www.f-secure.com/weblog/archives/archive-082006.html#00000954.
So, you might ask: what do we do now? I would recommend that you install the patches. If you don't use wireless normally you can stop the four services that Intel software needs (Intel(R) PROSet/Wireless Event Log, Intel(R) PROSet/Wireless Registry Service, Intel(R) PROSet/Wireless Service, Intel(R) PROSet/Wireless SSO Service). I put them on manual so they don't start automatically, but if I need to connect to a wireless network I can manually start them.
This way you at least won't be vulnerable, but your machine will be a bit slower due to bugs in these services.
Let's hope Intel will release a fixed version soon.
The easiest way to start and stop these services (so you actually run them only when you really need them) is to create a batch file that will do this job for you (so you don't have to click manually on all 4 of them). You can use the sc start <service name> and sc stop <service name> commands to perform this for you.
Thanks to reader Paul for reminding us about this.
Olli, Steve and Andrew wrote to tell us that they don't use Intel's utilities to manage their wireless card. Indeed, you can use the built-in Windows Wireless Zero Config service, in which case you only need to patch the driver for your wireless card, so you are not vulnerable. As the problem with CPU/memory leaks are in the management service, this is an effective workaround at least until the management service is fixed.
While the built-in configuration service works ok, I personally like Intel's utilities as they give you quite a bit more control over the wireless card and have pretty good monitoring programs (which sometimes come very handy, when you are troubleshooting problems with the wireless card).
Last Updated: 2006-08-25 07:50:18 UTC
by Bojan Zdrnja (Version: 3)
UPDATE: Small correction - Windows XP (before SP2), as well as Windows 2000, had very basic TCP/IP filtering options that did not directly depend on IPsec policies (although you were able to layer rules by using TCP/IP filtering with IPsec filters). However, Windows 2000 and XP (before SP2) lacked quite a bit on features - the biggest one is scoping of incoming traffic. This means that accepted traffic to allowed port(s) was able to originate from *any* IPv4 address. ICF (Internet Connection Firewall) in Windows XP pre SP2 also wasn't automatically enabled. This diary therefore explains how to use Windows XP SP2 firewall only.
With the release of SP2, Microsoft also made a pretty brave step (let's stay on the firewall in this diary) – the firewall was turned on by default and this inevitably caused some applications to break.
The idea of today's tip of the day is to encourage you to use the host based firewall in your corporations. I'm explicitly mentioning corporations as I noticed that in a lot of cases administrators in corporations simply turn off the host based firewall provided with SP2 because it prevents them from managing the machine remotely.
The host based firewall that comes with Windows XP SP2 is in no way perfect, but it can offer an additional layer of protection (and we all know that defense in depth is the only way to get more secure) that can help you a lot sometimes.
For example, take a look at the last month patch bundle Microsoft released. The most critical and remotely exploitable vulnerability was in the Server service (MS06-040).
Windows XP SP2 machines which were just running the host based firewall in the default configuration were automatically protected from this. Of course, these machines should still be patched (as soon as possible), but this at least gives some breathing space.
One thing that you have to be aware of is that the host based firewall that comes with Windows XP SP2 filters only inbound traffic. While this isn't as good as some commercial firewalls, it still offers decent nice protection. I won't go into why Microsoft didn't filter outbound traffic as well, but the bottom line is that if a machine gets infected with a malware, it can easily turn the firewall off (or add itself on the list of allowed programs, as many malware does today), so if you look at it this way, outbound traffic filtering isn't that important. The firewall in Windows Vista is much more powerful and does allow outbound traffic filtering.
Letting the good guys in
The biggest problem with the host based firewall not being used in corporations today is that, besides bad traffic, it also drops legitimate inbound traffic.
Typically administrators need access to IPC in order to remotely manage your machine, or they use remote desktop services to perform actions on client machines. The host based firewall effectively stops this and administrators have to rely to group policies in order to change configuration on client machines. As group policies are read only when machine is booted (with Windows XP, this is different with Vista) and remote users typically put their machines in standby, you can see why administrators don't like this.
UPDATE: Thanks to reader Chris for sending us some information about this. Group policies on Windows 2000, XP and 2003 machines will update every 90 (+30) minutes in a background group policy refresh interval. So, in this case, an administrator will still have to wait some time for new group policies to apply, but it's not as bad as I thought it is.
So, in order to still have some security, I typically recommend that administrators just put holes on their client machines which will allow connection from their designated management machine or network. This way the host based firewall will still protect the machine from everything (and everyone) else and the administrator can freely manage the machine remotely.
Adding such a rule is pretty easy. On a client machine you can add this through the Windows firewall control applet for a service or port you want to allow access to and select the appropriate scope. For example, you can allow access to port 445 just to IP address 10.0.0.10, which is your management server.
Fellow handler Swa (who else?) noted that the bad guys might know this (for example, a disgruntled employee in your company) and then wait at local Starbucks where your employees hang, get the internal IP address for himself and attack the target machine.
Windows actually comes with a pretty nice feature for different firewall profiles. In GPOs, an administrator can define different rules for the "Domain Profile" and different rules for the "Standard Profile".
Windows has a NLA (Network Location Awareness) service which determines where the machine is, and applies appropriate policy for the host based firewall:
Now, NLA will use the connection-specific DNS suffix to determine where your machine is. If it matches your domain, the Domain Profile will be used. Otherwise, the Standard Profile is used (you can check the connection-specific DNS suffix with the ipconfig command). So all you have to do now is setup rules you need for administration in the Domain profile, while completely closing machine in the Standard profile.
A bad guy could still spoof an Access point on a wireless network, for example, and have his own DHCP server to issue fake information to you, but this indeed raises the bar a bit.
Command line kung-fu
Seeing that command line kung-fu is very popular with our readers, I'd just like to end this tip of the day with some nice command line options you can use to configure the host based firewall on Windows XP SP2.
You have full firewall configuration options through the netsh command interface. This is very useful when you want to create a batch file which will open or close some ports on your machine.
I've used this to open the host based firewall to only one IP, so the anti-virus product we had was able to communicate with the client machines (poll their status, tell them to update definitions, etc).
So, let's say that you want to open port 10000 to the IP address 10.0.0.10, where your AV server is. This can be easily done with the following command line:
netsh firewall add portopening TCP 10000 Anti-Virus ENABLE CUSTOM 10.0.0.10
You can script this easily to do whatever you want. Just be aware of the limitation – you can't have port ranges so you'll have to open every port separately, in case you need to open more ports.
If you have some neat tricks with the Windows XP SP2 host based firewall let us know, and I'll update the diary with the best tips we receive.
Last Updated: 2006-09-11 23:05:04 UTC
by Swa Frantzen (Version: 13)
|#||Known Problems with this patch
||client rating||server rating|
||Botnets actively exploiting this in the WILD
Exploit available in easy to use package
|MS06-041||No reported problems
Original MS06-42: fixes a.o. a FTP vulnerability that;s well-known since 2004
First revision of the MS06-042 patch's buffer overglow has details public.
|MS06-043||No reported problems||Important||Less urgent|
|MS06-044||No reported problems||Critical||Critical|
|MS06-045||No confirmed problems||Critical||Less urgent|
|MS06-046||No reported problems||Critical||Important|
|MS06-047||No reported problems||Trojan dropper reported in word document by Symantec, Trendmicro(1) and Trendmicro(2). The dropper loads a backdoor: Trendmicro, Symantec.
See also diary.
|MS06-048||No reported problems||Trojan dropper in Powerpoint||Critical||Less urgent|
|MS06-049||Unconfirmed reports about corruption of files on compressed volumes.
[Windows 2000 only patch]
|MS06-050||No reported problems||Critical||Important|
|MS06-051||Although unconfirmed by Microsoft so far, there seem to be problems related to Terminal Services and multiple users loading certain DLLs as part of some applications. Details and fixes or workarounds are too sketchy so far.
See also the problem with .ini files and citrix at the citrix support forum.
We're still lookign for a more detailed discription of the problems.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
Last Updated: 2006-08-24 20:41:55 UTC
by Bojan Zdrnja (Version: 1)
The SCSI, DHCP and SSCOP dissectors are affected. Besides these dissectors, the IPsec ESP preference parser is also affected, when Wireshark is compiled with ESP decryption support (this is probably the case in most installations).
The new version (0.99.3), available at http://www.wireshark.org/download.html, fixes all these vulnerabilities.
If, for some reason, you can't upgrade, some workarounds are available at http://www.wireshark.org/security/wnpa-sec-2006-02.html (the original advisory). Basically, what you can do is turn off dissectors for affected protocols and disable ESP decryption.
Last Updated: 2006-08-24 17:23:04 UTC
by Jim Clausing (Version: 1)
Please choose a specific diary above to comment