McAfee DAT 5958 Update Issues

Published: 2010-04-21. Last Updated: 2010-04-21 21:08:19 UTC
by Guy Bruneau (Version: 3)
19 comment(s)

McAfee's "DAT" file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and loose all network access. We have individual reports of other versions of Windows being affected as well. However, only particular configurations of these versions appear affected. The bad DAT file may infect individual workstations as well as workstations connected to a domain. The use of "ePolicyOrchestrator", which is used to update virus definitions across a network, appears to have lead to a faster spread of the bad DAT file. The ePolicyOrchestrator is used to update "DAT" files throughout enterprises. It can not be used to undo this bad signature because affected system will lose network connectivity.

The problem is a false positive which identifies a regular Windows binary, "svchost.exe", as "W32/Wecorl.a", a virus. If you are affected, you will see a message like:

The file C:WINDOWS\system32\svchost.exe contains the W32/Wecorl.a Virus. 
Undetermined clean error, OAS denied access and continued. 
Detected using Scan engine version 5400.1158 DAT version 5958.0000.

McAfee released an updated DAT file, and an "EXTRA.DAT" file to fix the problem. An EXTRA.DAT file is a patch to just fix the bad signature. McAfee's support web sites currently respond slowly and are down at times, likely due to the increased load caused by this issue.

Several readers reported that this procedure worked to recover:

1 - Boot the system in "Safe Mode"
2 - copy extra.dat in c:/program files/common files/mcafee/engine
3 - reboot.

If you lost "svchost.exe", then you need to copy it back to c:/Windows/system32/svchost.exe while in safe mode. This fix has to be applied locally at the workstation. However, it may be possible to do this remotely if your workstations support Intel's "vPro" technology. We should have a link to instructions shortly.

Our reader Jim wrote in about how he managed to get some systems back remotely, as long as svchost.exe was not deleted or moved. In this case, the computer will be in a reboot loop. Here is what Jim wrote:

I created a batch file to run the following command:

echo f | xcopy.exe {server}netlogonextra.dat 
   "c:program files\common files\mcafeeengine\extra.dat" /R /Y

I put this batch file and the extra.dat in the netlogon folder.

I then set the computer configuration>windows settings>scripts>startup to run this command in a GPO that gets applied to all computers.  Then link the GPO to the domain root, or wherever is appropriate.

Upon reboot the computers process this command and so far we seem to be good to go, "mostly".  There have been a few cases where the files end up missing.

 

ISC reader Linnie wrote in and indicated this method works as well:

- Copy the EXTRA.dat file to c:program files\common files\mcafeeengine
- copy the svchost.exe to c:windows\system32
- Reboot, everything is back to normal.

 

Additional information from McAfee: http://community.mcafee.com/thread/24056?tstart=0
McAfee Knowledgebase Article: https://kc.mcafee.com/corporate/index?page=content&id=KB68780
EXTRA.DAT file: http://home.mcafee.com/VirusInfo/VirusProfile.aspx?key=265240.

THANKS TO ALL THE CONTRIBUTORS! We got too many to mention here. Please keep it coming using our contact page: http://isc.sans.org/contact.html . I haven't counted the submissions, but they may be at a hundred now. Some report about networks with thousands of down machines and organizations who had to shut down for business until this is fixed.

NOTE: We do have some journalists who would like to talk to someone whose network got affected. In particular, if the network was large. Let us know if you are willing to talk about this in public. We will not forward your contact information unless you specifically ask us to.

 

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

19 comment(s)

New OWASP Top 10 - Final Release

Published: 2010-04-21. Last Updated: 2010-04-21 15:52:42 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

The Open Web Application Security Project (OWASP) released an updated version of its "Top 10" [1] . If you are in any way responsible for the development, maintenance or general upkeep of web applications and related infrastructure, this is a MUST READ document for you.

According to the OWASP press release, this update focuses more on "Risks" vs. "Vulnerabilities".

 

[1] http://www.owasp.org/index.php/Top_10

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
0 comment(s)

isc.sans.org SSL Certificate and URL extensions

Published: 2010-04-21. Last Updated: 2010-04-21 15:47:35 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

We recently installed a new SSL certificate for "isc.sans.org" . Our goal was to support some of the old ISC hostnames like incidents.org. However, we had reports that some browsers didn't support the new certificate. As of today, this should be fixed. However, if you are still having issues, please let us know.

Before you send your message, please click on the "Debug" link at the bottom of the page (it is a bit hidden in the dark blue footer). Please include the output of the debug page to make it easier for us to help you. This is true for other bug reports as well.

Bug reports may be submitted via our contact page [1]  or via email to handlers@sans.org .

URLs to test the SSL certificate: https://isc.sans.org/login.html and https://isc.sans.edu/login.html (the index page includes content from non-SSL sites)

Another "public service" announcement: Our URLs end in ".html" for the last couple years. However, many links still point to the old ".php" version. We are using redirect to accommodate them. If you are linking to ISC, please make sure you link to the ".html" version.

[1] https://isc.sans.org/contact.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: ssl
0 comment(s)

Comments


Diary Archives