Hacker News new | past | comments | ask | show | jobs | submit login
Microsoft security tools nuking Chrome browser (zdnet.com)
125 points by FrancescoRizzi on Sept 30, 2011 | hide | past | favorite | 38 comments



On September 30th, 2011, an incorrect detection for PWS:Win32/Zbot was identified. On September 30th, 2011, Microsoft released an update that addresses the issue. Signature versions 1.113.672.0 and higher include this update. http://www.microsoft.com/security/portal/Threat/Encyclopedia...


case closed?


The sad reality is that a modern app like Chrome does look a lot like malware. It does a bunch of crazy things you might not expect a regular piece of software to do - manipulating file permissions and spawning large groups of processes, installing into a rather obscure part of the user's appdata folder instead of into program files, downloading arbitrary payloads from the internet and then using those payloads to modify executables on the user's machine...

It's always unpleasant when you get flagged by a virus scanner. Antivirus vendors basically ignore you unless enough of your customers complain to get their signature database updated. Hopefully in this case, since it's a high-profile application (Chrome), Microsoft will address the problem quickly.


I'm going to guess that this is also partially a consequence of Chrome's update strategy - presumably Microsoft has a bank of machines with commonly installed software that they regression test malware updates with - but Chrome is updating so frequently and 'transparently' (i.e. different than most commonly installed software) that Microsoft's test framework wasn't prepared to deal with it, and chrome 11 or 9 or whatever is still passing with flying colors while 14 is getting zapped in the real world.


The delta based in-place patching technique that chrome uses to update itself probably looks really fishy from the outside as well.


Chrome does not update the running exe - it makes a new copy in another directory. Then the launcher checks for latest directory and runs that.

Existing executables are not modified. Only created and deleted.


I didn't even know Microsoft had an antivirus. If it is flagging chrome as a virus then I am guessing its prbably giving other viruses a free ride :)


MSE is an excellent antivirus programme, particularly given the price.

As the article says, it shares its engine with Forefront Endpoint Protection, an enterprise solution used by thousands of businesses world-wide. This is a once-off mistake for an otherwise stellar programme - it happens to the best of us - and isn't indicative of the entire solution.


I’ve been always uneasy with the “crazy things” Chrome does on Windows, mainly because of my general dislike for apps that disregard important vendor recommendations like where programs should be installed.

I understand that the main upside for Chrome is the unobtrusive automatic updates. What I would like to know is what are the possible downsides. Do you or anyone else know about any discussion about that or research into that?

(By the way, another modern app that uses appdata instead of programfiles on Windows is Dropbox.)


This is pretty normal. Microsoft itself even endorses this: The .NET Framework has a installation framework built into it (analogous to Java WebStart) called ClickOnce. It's a framework that doesn't require administrator access to install programs, but if you do that then you can't install programs to Program Files. So it installs the apps on a per-user basis to AppData.


Consider it ~/bin, on Unices, it is a standard way to do user installations.

If there was system-wide vendor neutral update mechanism, (like apt in Debian/Ubuntu, for example), I'm sure that Chrome team would use it in place of their own home-grown solution.


I doubt it, as no single packet manager has delta updates, which is a crucial asset of their own solution.

More importantly, they have no control over what comes in and goes out of the repositories. I doubt Google would want to deal with every single distribution personally.


Google's solution for Chrome on Debian and Ubuntu is to distribute a .deb package that installs not only Chrome, but also installs a reference to their own package repository. When the user updates packages on their system, it updates Chrome from Google's repository. Chrome does not update itself, nor can it, since the package installs it to /usr/bin, which would require a su/sudo prompt to get access to.


It would be interesting to see exactly what heuristics were responsible for marking Chrome as malware.

I'm guessing that it's based on something much simpler than what you describe since it's identified it specifically as Zbot.

Too bad MSE isn't open source :)


Anecdote: one side-project I'm working on is a simple DLL injector that can insert arbitrary DLLs into other processes at launch time. It's been used out in the open for over three years, but only one security suite (Comodo) blocks it from running. Is modifying other processes' memory not as suspicious as Chrome's behaviour?


Does it need Administrator privileges to run? If so it's not really a security hole since by the act of giving it enough permissions to run you could have done it yourself (in a way).

It's like the "I'm logging in as root and can change other people's files." sort of security 'flaw'.


Yeah but isnt MSE definition based? How is there a hash collision between the zbot exe and chrome? Its very odd. Or maybe MSE has started doing heuristics, but if so, I don't see it in any menu.


Nearly EVERY modern antivirus uses heuristics, and all of them use more complex signatures than simple hashes. It's quite possible that some byte signature that was added to catch some sort of malware is also present in Google Chrome.


This is probably a false positive from the file scanner portion of MSE. I'm pretty sure those are purely hash based, because it usually happens without executing any code.

We've had a few internal executable test applications get flagged(and then nuked from orbit) by Trend's virus scanner before while the compiler was finishing the linking step.


I found the setting. MSE calls it "behavior monitoring."


How do these malware-signature-matching mechanisms work? What are the odds that Chrome produces the same matchable-characteristics as Zeus malware? I don't want to leap to the conclusion that something fishy is going on here.


With some of the more advanced things like NaCl, it wouldn't surprise me at all if some of the functionality looked the same, or even had quite a similar purpose.

We don't know if the malware signature is on bits that do bad things, or just bits that had been unique to Zeus until now.

Edit: Also, some people are reporting no problems. It could be that those Chrome instances really were infected. We don't know where they got the download for Chrome from.


Ok, here's the high-level overview. An antivirus scanner uses the following (basic) types of detection:

1. Hash-based. This isn't as common nowadays, as there's a lot of malware that will generate a unique copy every hour or so.

2. Signature. This can be as simple as a byte sequence (i.e. anything with "C:\Badfile.exe" in it is a virus), to more complicated code using wildcards.

3. Heuristic. This can refer to anything from "files with an invalid digital signature are bad" to "files that have a high entropy and have no publisher are bad".

4. Emulation. The AV runs the file in a CPU emulator, tracks what it does, and attempts to determine if it's bad.

5. Behavioural. The AV lets the file run, tracks what it does, and then might stop it if it does enough "suspicious" actions.

So, in short, with all the various types of detection that modern antiviruses use, false-positives are almost inevitable. The teller is how fast the vendor reacts - and in this case, Microsoft seems to have reacted rather quickly.


Doesn't code signing give any advantage to Chrome? If an executable and all its dependent libraries are signed by trusted party MSE ought to be able to lower its aggression level a bit. How likely is that a Google signed Chrome exe could be injected or rewritten with malicious code without invalidating the signature? That coupled with some white listing and these type of things should never happen.


I don't think that's a good idea. At least not in general. Signing only proves the identity of whoever signed it. It doesn't say whether the signers infrastructure was infected at the time between compiling and signing.

Granted. Google is probably safe. But can you tell that for every thirdparty vendor who has a code signing certificate (they are quite easy to get)


That should be "nuked", the issue was fixed in under an hour this morning.


This happened to me today. MSE does give the choice of what action to take, I figured better safe than sorry. I'll reinstall once it gets straightened out.


Oh dear. No matter what the reality of the situation Microsoft ends up looking really terrible here.


No they don't. This happens all the time with various anti-virus software. Modern software is complex.

If it didn't get fixed promptly (it was fixed almost immediately), that's where looking terrible starts.

For what it's worth, I run MSE & Chrome (2 run the beta, 1 runs release) on all 3 of my Windows 7 computers and none of them have flagged Chrome so far, so people's mileage may vary.


Doesn't look terrible to you, but just wait, sometime today I'll get an email from my mom with a link to a news story about how "microsoft was automatically uninstalling chrome."


Wrong. "That chrome thing you installed was really a virus! I'm going back to the blue internet button, that worked better"


That's a technical answer to a perception issue. While you are correct, there will still be negative perceptions of Microsoft stemming from the incident, because a large fraction of the population will not think along those lines.


Not at all. Microsoft found and fixed this same-day. http://www.microsoft.com/security/portal/Threat/Encyclopedia...


It's the same problem with iTunes on the windows platform. When you sync your iOS device to your computer it requires so much personal information (e.g music, movies, photos, contacts) that this process looks fishy. Windows is rarely ever ok with this. Seems no different with Chrome.


[iOS5]...to the iCloud!...[/iOS5]


When you have a list of constantly-updated virus signatures being matched against a set of constantly-updated program binaries, this sort of thing seems like only a matter of time...


I just reinstalled Windows 7 with Chrome on my desktop PC last night. It will be interesting to see what happens when I get home today.


The virus definition that caused this has been long pulled. Nothing will happen.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: