Direct patch download links for MS10-002 KB978207


Microsoft had released the out of band patch to resolve Internet Explorer vulnerabilities, see KB978207 and MS10-002 for additional details.

The patches for IE6, IE7, and IE8 are available on Windows Update and Microsoft Update.  Unfortunately for me, our business proxy blocks access to these sites.  We also have to go through a corporate vulnerability rating process, and if the vulnerability rates severe enough, a deployment plan will be developed, and tested, and scheduled…. long story short, without intervention on my part, it will be a long time until my machine sees any critical updates.

The ISC has rated this vulnerability at it’s highest risk level, PATCH NOW!

I manually downloaded the patch from the Microsoft download site.  You can find the patch for all OSs and versions of IE here.

Vista x86 patch to address 4GB+ of RAM


Remko Weijnen has released a kernel patch that allows x86 versions of Windows Vista to address more that 4GB of RAM.  I’m going to try it on my home Vista PC tonight.  The patch has been tested with SP1 and SP2.

Remko explains how his patch works, and states that the reason why Vista x86 can’t address more than 4GB of RAM isn’t a hardware limitation… it’s a Microsoft licensing limitation.

MS08-067 vulnerability, exploit, and reverse engineering in detail


Since Microsoft released the out of band patch detailed in MS08-067 yesterday, an exploit and worm have already been developed and seen in the wild.  Dave Aitel announced the exploit yesterday in his DailyDave mailing list. SecurityFocus has the exploit available for download hereAlexander has also published his decompiled version of the vulnerable function.  Stephenl has a nice description of how he reverse engineered the patches to determine the specific vulnerability.

The ThreatExpert Blog has a very nice description of how the worm, named Gimmiv.A operates. Gimmiv.A creates three files in the %system%\WBEM\ directory: winbase.dll, basesvc.dll, and syicon.dll.

ThreatExpert reports

“After dropping and loading the aforementioned DLLs, the worm will collect system information from the compromised computer, collect passwords from the Windows protected storage and Outlook Express passwords cache, and post collected details to a remote host. The details are posted in an encrypted form, by using AES (Rijndael) encryption. 

Details collected by Gimmiv.A are then posted to a personal profile of the user “perlbody”, hosted with http://www.t35.com hosting provider. At the time of this writing, there are 3,695 entries in that file. Every line contains an encrypted string, which could potentially conceal current victims’ details, indirectly indicating how many victims have been compromised by this worm so far.

The most interesting part of this worm is implemented in the DLL basesvc.dll. This DLL is responsible for the network propagation of the worm.”

If you cannot immediately patch your systems, the best defense is to restrict access to ports 139 and 445.

For additional detail, see this Microsoft Security Vulnerability Research & Defense blog posting.

The Microsoft Malware Protection Center has a page dedicated to Gimmiv.A, which they are calling a trojan rather than a worm.

McAfee has a nice description of the exploit code as well.

You can verify your anti-virus vendor detects Gimmiv.A at virustotal.com

VMware Express Patch for ESX and ESXi 3.5 now available


Yesterday I wrote that VMware was promising a patch by noon PDT today to address their licensing issue that caused version 3.5 Update 2 ESX and ESXi machines not to power on, suspended machines not to leave suspended mode, and machines not be able to be migrated via Vmotion. 

Well, VMware has released patches for both systems ahead of schedule.  You can read about the patches here, or go directly to download the ESX or ESXi version of the patch.

You can read a huge thread on the VMware Communities forum about the experiences network administrators have had with this bug.  It’s currently 42 pages long, and lets just say many administrators who have tauted VMware’s software as the answer to high availability challenges have egg on their face today.  The thread is so lengthy the moderator has created new separate threads for technical and non-technical feedback.

You can also read a post from VMware CEO Paul Maritz  about this issue.

Novell has released patches for DNS cache poisoning vulnerability


Novell has released patches for novell-bind on OES2 and named.nlm on Netware that address the deficiencies in the DNS protocol and common DNS implementations that facilitate DNS cache poisoning attacks described in CVE-2008-1447.   

Patches for bind running on SuSE Enterprise Linux Server (SLES) 9 and 10, plus openSUSE 10.2, 10.3, and 11.0 were released previously.   

See TID 7000912 for details. Security patches are available from the Novell download site.

These patches should be applied as soon as possible.  Metasploit exploits of this vulnerability are already available.

Identifying and Clearing Groupwise GWIA Queues of Corrupt Messages


When the Groupwise GWIA gateway has problems sending or receiving mail, it’s often the result of a corrupt message clogging up a queue. The easiest way to troubleshoot the problem and restore mail flow is often to down the GWIA and rename the queue folders.

To accomplish this on a Netware server you can stop the GWIA and MTA by pressing F7. Once they have unloaded, browse to the domain\wpgate\gwia directory and rename the following directories:

  • 000.PRC
  • DEFER
  • GWHOLD
  • GWPROB
  • RECEIVE
  • RESULT
  • SEND
  • WPCSIN
  • WPCSOUT

Restarting the GWIA and MTA will recreate these folders. If mail starting flowing again, you can bet that the cause of the problem was a bad message in one of the renamed folders. Move a few messages at a time from the renamed folders to their corresponding new folder. The message flow should continue until you find the corrupt message, which is often the oldest message.

Once the corrupt message is identified, delete it or move it to a different location. This should allow mail flow to resume as expected.

For additional details, see TID 10075205, TID 10054298 and TID 10008353.

In a worst case scenario you may need to delete and reinstall GWIA per TID 3674238. Don’t forget to apply any applicable patches.