Once upon a time, a software upgrade was a physical box with a CD. It looked like this:
Then the internet happened, and companies started using “update managers”.
Things got spammy. Every time you’d turn on a computer, it would ask you if you want to update Java and please upgrade to the latest Adobe Acrobat Reader.
A lot of people just ignored the upgrades, leading to version skew. (That where people are using many different versions of the same software.)
So if you made a web app as recently as 2011, you had to make sure it works in Internet Explorers 9, 8, 7, and best of all 6. Fun!
But in 2008, Google shipped Chrome with a new invention to fix this problem.
As Chrome developer Ben Goodger explains,
Autoupdate is one of Chrome's killer features. [...] Long before we launched publicly in 2008, the autoupdate project was one of the very first we started working on. The idea was to give people a blank window with an autoupdater. If they installed that, over time the blank window would grow into a browser.
How cool is that!
No more version skew. No popups. Every time you run Chrome you get the latest greatest version.
There was just one problem.
It worked so well that auto update became ubiquitous. Today, the thermostat where I live auto updates itself, over WiFi. Things that used to be simple are now complex and flaky. For example, my phone will occasionally just grow a new bug one morning and, say, the camera stops working. Not all teams are nearly as reliable and careful and awesome as the Chrome guys.
Not all teams are as trustworthy as the Chrome guys, either, which means there's a much bigger problem:
Through ubiquitous auto updaters, we’ve totally pwned ourselves.
There are now probably 10+ separate organizations that can run arbitrary code on my laptop whenever they want. Same for my phone. Fundamentally, that’s how most auto update mechanisms work.
Most updaters connect to a central server, and if there’s a new version available, they automatically download it and run it.
That’s convenient, but now you're at the mercy of whoever controls that server and has that signing key (assuming they even sign updates, which not all of them do). Just last week, Kazakhstan announced they’re going to MITM all HTTPS traffic in their country. Other governments with similar impulses but a bit more subtlety can leave HTTPS alone but compel their companies to issue an autoupdate. If they want to be sneaky, they can serve a clean version to most users and a compromised version only to specific people, filtered by IP. Compelling Google to do that for you is probably hard, but what about some dude who wrote a Notepad++ plugin?A popular program with an autoupdater is a lot like a botnet. The owners can push some code. Within a few days and without any more human intervention, millions of computers are running it. The difference is users install them by choice!
How can we fix this?
Autoupdaters aren't going anywhere. They're too useful. So the question is not "how do we get rid of autoupdaters", it's "how can we make a secure autoupdater".
If we must have autoupdaters, I’d like mine to use multisigs and deterministic builds.
It works like this: multiple people have to sign each update, say four out of a list of six trusted keys. Those are held by six different people, ideally spread across different countries. Trustworthy people and organizations, the same ones who are doing the code reviews and audits. When a new version is ready, each of those six checks out the code and builds it themselves. Because it’s a deterministic build, if they’re all using the same commit hash, they’ll all get the same binary, byte for byte. Finally, they sign with their key.
This makes pwning people thru the auto updater a lot harder. There’s no single private key that one person can lose, giving an attacker that power. Getting four out of the six signers to sign an update with, say, a backdoor, is a lot harder than one.Finally, it would add some accountability. Companies, auditors, and open source developers would be signing their name to each release. I’d like to know which people have the power to run code on my machine. Today, there are a lot of people who have that power, and I have no idea who they are.