Software in the modern world is connected, usually to the Internet, which means it is exposed to all kinds of attacks. The upside of connectivity is that people can use their phones to check email, websites, and the weather, as well as get driving directions with traffic data in real time. The downside is that users have never been more exposed to attack, and that exposure will only increase.

As problems in software are identified, the software is updated, and these updates are made available to customers who then deploy them (I hope). A typical Linux vendor fixes more than a thousand security issues a year, and other large vendors aren't far behind. They also ship updates to fix non-security related bugs, add new capabilities, and generally make better products.

Modern Building Blocks

Like interconnected systems, the value of software increases as it becomes more interconnected. Rather than reinvent the wheel and write your own HTTP(S) client, you simply call the best one offered by whatever language you're using. Developers have been doing this for decades through shared libraries, and it has become easier as vendors have added package management and as software languages have added repositories.

I have to admit, when I write Python or Ruby code, I rarely think about the magic that goes into statements like import foo; things just work. However, this opens up potential security holes. What happens exactly when you import foo? Well, it may cause an error if the package is not installed, or in some languages it may cause a software component to be downloaded directly from the Internet. If this action is not done securely, it could allow an attacker to insert malicious code into your system. But, wait, can an attacker really inject malicious software into software download on the fly? Yes.

To quote Wikipedia regarding FinFisher [1], for example, "The surveillance suite is installed after the target accepts installation of a fake update to commonly used software." Oh, and it also supports Linux (as well as Windows, Mac OS X, Android, iOS, BlackBerry, and Symbian). Additionally, in 2013, a number of revelations about spying capabilities and widespread usage were reported, which means the issue of compromised updates is no longer a theory but is actually happening. (Also see the "Internet Traffic Misdirection" box.)

Automatic Updates and Imports

To make matters worse, users really want automated updates and software imports; having things just work is extremely valuable. Having to babysit software updates across a few hundred systems instead of just running a single command line can be the difference between 15 minutes and one to two weeks of work. The good news is that most major vendors have gotten a lot better at releasing software that works with relative ease.

Automated processes are also much better for end users. For example, my parents have computers capable of automatically downloading and installing updates. This Christmas when I checked them, they were all actually up to date; in the past, they often had been missing security updates for weeks or months. The bad news is that many of these import and update systems do not use encryption or code signing to protect the software that you are downloading and running.

What You Need in an Update System

Most people agree that secure and reliable update and software deployment mechanisms are a good thing, but what exactly do you need in an update system for it to be secure? Please note that, for the purposes of this article, I'm going to equate software updates and software delivery as a single problem.

What do you need in an update system? At minimum, you need notification that updates exist, and you need a way to deliver these updates to the client securely. Chances are your system will need a pull mechanism on the client, because people are behind firewalls in most cases. You should also ensure that your updates can be delivered securely over untrusted and potentially hostile networks, like your local coffee shop's wireless LAN or the Internet. You should probably also shoot for allowing updates via servers or systems that you don't control (e.g., internal mirrors, web proxies, etc.), because some people will have to use them.

Generally speaking, the solution to moving data securely over untrusted networks and systems is cryptography. In this case, you're probably mostly concerned about authentication of the data; that is, you don't want it tampered with. You usually don't have to worry about the secrecy of updates, especially in the open source world, because people can just go to the vendor's FTP site and grab a copy of the update. That means you need end-to-end authentication of your data.

An update system should also handle compromises, accidents, and so forth. As I wrote this article, the OpenSSL website was compromised [2], not through any fault of their own. The hosting provider used poor passwords on the server hosting the virtual machine that ran www.openssl.org. Obviously, compromising this system would have allowed the attacker to modify or add new files to the /source/ directory; fortunately, they did not, also OpenSSL signs all their source code releases, using a key not stored on the server. The most practical solution to this class of problem is to use strong cryptographic signing of the source code or software that end users can easily verify. This means adding encryption key handling, which is not easy to get right. Fortunately, however, the TUF [3] guys have worked this all out (more on this later).