Is any one else seing this alert - Shh/Updater-B False positives

Ok, thanks very much for the reply. We're down to a manageable number of false-positives. Around 50 out of 7000+ so we're getting back to normal.

Trying to clean up the last few clients.

I am attempting to re-install Sophos on a Windows Vista PC.

Sophos Auto Update and Sophos Remote Management System appear to be installed.

Sophos Anti Virus is not.

Prior to re-install all Sophos programs have been un-installed. File system (Sophos and temp) cleaned up. Registry cleaned up.

Sophos Anti-Virus CustomActions Log.txt says:

2012-09-25 09:39:57 Error getting boot driver status

Thie message is repeated if I attempt to run the Sophos Anti-Virus.msi directly.

InstallShield says:

The wizard was interrupted before Sophos Anti-Virus could be completely installed.

I have reinstalled Sophos an a number of other machines, and while I have had different issues on some of them, I have managed to get them all reinstalled.

Short of a Windows re-install, any suggestions?

I too am seeing the issue were we have ~60 (out of >8500) endpoints that have a blank Update Policy. Cannot have them comply with the Update policy because the option is greyed out. What is interesting is that they display that they are Same As Policy. I've tried to update and Protect from the console with no success. It may be that these endpoint have the SophosUpdate Service not running and all of these indicate they've last updated on the 19th (day of False Positive event).

Any clues?

I am pretty much all back up and running now after this madness...

However, I have 1 machine that is just causing untold grief.

It is an XP machine, and it just refuses to update all I get is the following in the Enterprise Console...

verification of update files failed. the files did not match the manifest. [0x00000005]

I've tried deleting from the console and protecting it again, but nothing has worked.

Hello mreaves,

this error is often caused by an incorrect date on the client.

Christian

OK, any ideas how I remedy that?

Hello mreaves,

well, either locally on the client or if you can access it remotely by issuing the DATE and TIME commands with e.g. psexec.

NB: If you view the computer details in SEC you should see some messages/alerts with a "funny" date if it is really off-date

Christian

Very concisely put, Jak

@apeeler (and TWIMC): Probably the first time you've got hit by a FP. As Jak said, the outcome depended on the settings you use - and with the recommended settings there wasn't a real problem at all except for the cluttered QMs (and if your users don't have special rights this too is almost irrelevant).

It's all about probabilities. As long as you don't identify a file byte by byte there's always the risk of mistaking it for another. Assuming you do you'd have to have a complete collection of all malware, present and future, in order to catch polymorphs and their like. Now that's not only improbable, it's impossible as there is not enough storage available in the whole universe. Doing it the other way round (identifying clean files) also won't work - this time in addition because only for small and simple ones you can determine with absolute certainty that they are clean. Again you'd have to have copies of all these available in advance.  

Thus you (i.e. an AV writer) have to deal with probabilities and the risk of false positives and (don't forget) false negatives. Ignoring the latter for the moment, from the above it should be obvious that even forgoing "heuristic" scanning and other generic methods but instead relying on "signatures" only won't eliminate FPs. The only way to avoid them is completely abstaining from scanning (for the price of 100% false negatives of course).

Vendors have to find a balance in both their products and (business) processes, trying to minimize the risk without making their product pointless. As with all tools there's some residual risk for the user and usually the customers have also some options available to adjust their risk according to their environment.

Using aggressive, non-recommended settings one must be aware of the consequences. One could argue that there shouldn't be any Move and Delete options - nevertheless it's somewhat absurd to claim you didn't tell me that delete actually means delete. The out-of.-the-box settings weren't harmful and you weren't required to change them (in fact, the recommendation is to leave them as they are).

The following will rub some the wrong way - no insult intended though

Apart from this - AV is not the only source for disasters (and not even the most common). You are skating on thin ice anyway if you don't have the means and/or procedures to deal with site-wide problems. AFAIK even Delete did not bring machines down or corrupt the OS, made them unmanageable or cut off communication. You may call it a disaster, but among them it's a midget at best. Instead of frantically searching for another supplier (you can always do this later) you should take the opportunity to assess your current setup and to identify potential shortcomings - be it in staff, equipment or processes. The next disaster could be a real one.

Again - this is not meant to offend anyone

Christian

Update for anyone watching this thread we have released some new endpoint fixes and have an exe to run on end points that are being affected. 

the initial KBA http://www.sophos.com/en-us/support/knowledgebase/118311.aspx has not been changed i believe but certainly the 

http://www.sophos.com/en-us/support/knowledgebase/118323.aspx

does relect thee changes, if anyone is affected please keep an eye on this KBA, thank you.