Why Silent Updates Boost Security | Hacker News Reader

Why Silent Updates Boost Security

techzoom.net

10 pointsbriansmith7 comments

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.

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com