Hacker News Reader

Comment by kevingadd | Hacker News Reader

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.

View on HN

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.

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

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

Reply on news.ycombinator.com