Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Problems with Intel wireless drivers

Published: 2006-08-24
Last Updated: 2006-08-25 15:21:14 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
Three weeks ago Johannes wrote a diary (http://isc.sans.org/diary.php?storyid=1535) about vulnerabilities in Centrino device drivers for Windows and the PROSet management software.

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.

UPDATE:

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.

UPDATE 2:

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).


Keywords:
0 comment(s)

Tip of the day: using host based firewall on Windows XP SP2

Published: 2006-08-25
Last Updated: 2006-08-25 07:50:18 UTC
by Bojan Zdrnja (Version: 3)
0 comment(s)
I'm sure almost everyone knows about the host based firewall that was added to Windows XP with the Service Pack 2. Although Windows XP had a possibility of filtering network traffic before the SP2 was released, it was rarely used as it required use of IPsec policies.
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.

Using profiles

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.
Keywords: ToD
0 comment(s)

Microsoft August 2006 Patches: STATUS

Published: 2006-09-11
Last Updated: 2006-09-11 23:05:04 UTC
by Swa Frantzen (Version: 13)
0 comment(s)
Overview of the known problems and publicly known exploits ofthe August 2006 Microsoft patches.

# Known Problems with this patch
Known Exploits
client rating server rating
MS06-040 Issue with:
  • Huge memory allocations on Windows 2003 server SP1 (32bit & 64bit), XP (64bit) and 32bit application.
  • Microsoft Business Solutions–Navision 3.70 on above platform.
  • Websense Manager when using terminal services
Fix:
  • Hotfix available by calling Microsoft.
More information:
Botnets actively exploiting this in  the WILD

Exploit available in easy to use package



read more...
PATCH NOW
PATCH NOW
MS06-041 No reported problems

Critical Critical
MS06-042 Critical issue:
  • This patch introduces a new arbitrary code execution vulnerability on MSIE 6 SP1.
Fix:
  • Microsoft re-released MS06-042 on Aug 24th 2006.
  • It is unclear if the hotfix that was available earlier fixes this problem as well.

More info:

Issue #1:
  • MSIE 6 SP1 crashes while using multiple application such as Peoplesoft, Siebel, Sage CRM and websites using HTTP 1.1 and compression such as the register.
  • Roll-up patch so it has all older issues as well.
Workaround:
  • Workaround to disable HTTP/1.1
  • Use alternate browser (for problem sites)
Fix:
  • Upgrade to MSIE 6 SP2
  • The re-release of the August 24th is intended to fix this. The fix was supposed to be published by Microsoft on August 22nd, 2006 but was delayed.
More Information:
Issue #2:
  • CA Unicenter Service Desk can cause MSIE to crash, on XP SP2 and Windows 2003 SP1
Workaround:
  • Use the supported Firefox or Mozilla browsers
  • KB923996
Fix:
  • The re-release of MS06-042 is not fixing this problem as far as we know.
More information:

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.
  • Microsoft released it first on the 22nd
  • actual code fragments were publicly released on the 24th after the patch was updated
PATCH NOW
Important
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.
Critical Less urgent
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]

Important
Less urgent
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.

Critical Critical

We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
0 comment(s)

Wireshark (ex Ethereal) multiple vulnerabilities

Published: 2006-08-24
Last Updated: 2006-08-24 20:41:55 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)
Multiple vulnerabilities have been reported in Wireshark dissectors (dissectors are Wireshark modules which analyze particular protocols – hundreds of protocols are supported), as usually. Reported vulnerabilities can cause a denial of service (resulting in Wireshark crashing), but also remote execution.

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.

Keywords:
0 comment(s)

* MS06-042 reissue

Published: 2006-08-24
Last Updated: 2006-08-24 17:23:04 UTC
by Jim Clausing (Version: 1)
0 comment(s)
The anxiously awaited reissue of the patch from bulletin MS06-042 is now live.  Time to re-apply the patch on Internet Explorer 6 Service Pack 1 for Windows XP Service Pack 1 (all versions) and Windows 2000 (all versions)
Keywords:
0 comment(s)
Diary Archives