Google Chrome and Silent Patching

This morning I opened one of the Swiss Sunday newspapers and Google Chrome made it to the front-page with a “best practice approach” for deploying security updates. In the article itself it was claimed that Chrome is one of the best browsers with regards to security as the deploy patches silently, without letting the user know, even if Chrome is not running and there is no way to disable this. Here are some of similar stories:

• Report: Using silent updates boosts browser security
• Google Chrome... updates without asking.
• Google is Wise, Chrome Updates Silently

Give me a break here.

I am really tired of hearing those things. When Chrome shipped, three things actually hit my inbox:

• Chrome was shipped (in a Beta) with a few pretty significant vulnerabilities in, which were known for quite a while (like the carpet bombing flaw). The excuse by Google was “it is just a beta”. Tell me please, how you would comment if we would have done the same with Windows 7.
• I got quite some mails by angry customers and journalists telling me that Chrome found a way around User Account Control as Chrome installs without UAC kicking in. Journalists called as they claimed to have found “a severe vulnerability”, customers called as they were angry with us as Chrome simply popped up all over the place in their network even though their user were non-admin. Well, well, Chrome simply installs an executable in the user context. Directories which the user has write permissions. So, for sure Chrome can install – really bad practice in my opinion.
• There was a pretty strange paragraph in the EULA which was then removed later.

And now the silent patching. A few years back, when we designed Windows XP SP2 we talked about switching Automatic Updates on by default. This caused a lot of people screaming and telling us that it is unacceptable to switch AU on by default (which we actually do in the meantime). We recently updated the Windows Update client – and it caused a lot of you to scream and tell us that it is unacceptable for us to silently update a component on Windows. And we heard you loud and clear. And now I hear that Chrome is best practice because they silently fix security vulns? And you cannot even switch this off? So, what is the policy the industry shall follow?

I agree that the most secure way for consumers would be to automatically fix security vulns. This is actually what I tell my parents: Simply install security updates. This is for consumers and there is an option. Not having an option is unacceptable – at least for me. Additionally, again for the consumer, having Anti-Malware being part of the Operating System out of the box and enable by default would be desirable. However, this is not acceptable today for competition reasons.

So, what I do not get is why people do not look at these problems holistically and more from a policy perspective rather than from a company by company perspective. Silently installing components without even giving me the option to choose is not acceptable today for me – but I want to have the option to do it if I want.

And finally: I would question the enterprise-readiness of such software. At least, I would never deploy it in an enterprise environment.

Roger

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  May 11, 2009
  The comment has been removed

• Anonymous
  May 11, 2009
  Let's talk a little more about installing executables in the user context. Presumably this is a bad idea because malicious software run in the user context also has permission to write there?

• Anonymous
  May 11, 2009
  An interesting discusion point, although I don't think that automatic updating an operating system (which you have to buy) can be compared with the automatic updating of a browser (which is for free)...

• Anonymous
  May 11, 2009
  You don't have to buy any operating system, and why would that make a difference anyway?

• Anonymous
  May 11, 2009
  To contribute to the post - here is another view of the industry (competition) about Microsoft pushing updates via Windows Update - not even being automatic !! http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9132732&intsrc=news_ts_head Google is not one of the claimers, but we knoe why ...

• Anonymous
  May 12, 2009
  The comment has been removed

• Anonymous
  May 12, 2009
  I don't really understand the UAC comment in your article. If Chrome is able to install in the user context without intervention, then UAC has some serious flaws because malicious software would also be able to install in the user context? So the problem is in UAC, not in bad practice. Google just used what was available to them, just like malicious software would do.

• Anonymous
  May 12, 2009
  The comment has been removed

• Anonymous
  May 12, 2009
  asf - if the browser runs completely in the user's context and the user can update it without privilege elevation then so can malicious software. It doesn't have anything to do, strictly speaking, with browsers running as admin, just in a different and protected user context. Maybe you think it's not a security issue when users run arbitrary exes, but most people think we should at least try.

• Anonymous
  May 12, 2009
  The comment has been removed

• Anonymous
  May 12, 2009
  @asf: If the malware is running as standard user it can't install a shell extension. But it could modify Chrome in some way, for example, to steal passwords.

• Anonymous
  May 12, 2009
  The comment has been removed

• Anonymous
  May 12, 2009
  And at this point I think it's worth reminding people that Chrome is an open source program. How hard would it be to write a malicious version of one of the major DLLs or the chrome.exe file that works normally except for added malicious functionality?

• Anonymous
  May 12, 2009
  @Larry Seltzer: it depends on the config, but in a corp. env, yes probably. But there are a million ways to inject into other processes, and explorer.exe would be the main target probably. CreateRemoteThread or SetWindowsHooksEx does not care about any policy, only thing that stops it is a process running at higher IL (above medium or low depending on the parent process)

• Anonymous
  May 12, 2009
  The comment has been removed

• Anonymous
  August 14, 2009
  Isn't it what the ClickOnce do?