

Why Silent Updates Boost Security - briansmith
http://www.techzoom.net/publications/silent-updates/

======
sundarurfriend
I really hate it when suddenly out of the blue, my Comodo asks permission for
some random 'setup.exe' to change things in the Google Chrome folder. If
you're making me practise allowing this, you're making me learn to allow
cleverly contrived cracker attacks.

At the minimum, if you don't like asking user's permission to install stuff on
his/her own computer, please for heaven's sake _inform_ me (within the
browser) that you've got an update and are going to update yourself at some
random point in the future. Then, I'll have at least a very little amount of
confidence that this setup.exe isn't something evil.

There are many things wrong about Google's update mechanism from running a
GoogleUpdate.exe at startup and then continuously without permission (what,
are you Adobe?) to updating my software silently without even providing an
option for how it's done.

If you're trying for the IE marketshare, make what they want the defaults, and
give the advanced users _some_ way to customize things. I'd be happy even to
have even the slightly advanced options in an about:config window, rather than
not have them at all.

------
khandekars
Interesting paper. Thoughts about tradeoff:

1\. What if the update breaks some user code / extension and causes loss of
productivity? 2. What if the update server gets hacked (though highly
unlikely)?

On the whole, silent updates are useful when: a. attack surface is greater, b.
they are geared towards security fixes than enhancements.

~~~
deno
AD1: Possible solution might be signing updates. Microsoft already provides
way to sign assembly files. Ohama (Google update tool) uses HTTPS, but I doubt
they are signing files they download.

~~~
eru
Ubuntu also signs updates. And I guess they did not invent it, but took the
process from Debian.

~~~
deno
Still, if private key is compromised you can inject evil updates. And it might
be the case for teams that lacks necessary security policies, e.g. private key
is on same server as download server or is accessible from one.

Maybe requiring signing by several developers (so that if one key is
compromised it's still not a threat)? But that might be a little paranoid.

~~~
khandekars
Signing by several developers is a good idea. Also, the scheme might still
fall to man-in-the-middle attack. One possible solution could be to have
multiple update servers with the policy that, download update from one and
signatures from the other, subsequently verifying the integrity.

~~~
eru
The man-in-the-middle attack is not such a big problem in defending against a
short-lived attack. Ubuntu establishes the identity with the keys that you get
at installation.

