Software updates and TUF
SSL/TLS in an Update System
One thing that comes up a lot in update systems is the use of encryption for network traffic; typically, this means using HTTP over SSL or TLS. You probably don't want to do this. Let me be clear: Using SSL and TLS is a good idea for any network traffic, and I recommend update systems use SSL or TLS where possible. However, I recommend against requiring it – for several reasons.
First, using SSL and TLS will not prevent denial-of-service or blocking attacks; attackers will still be able to block the connection or cause it to drop. Second, anyone who wants to set up a mirror site, especially an offline mirror, may not be able to do SSL or TLS (especially if you require it to be a specific domain like *.example.org). Third, SSL and TLS can be attacked through the use of malicious certificate authorities, as has been spotted in the wild, so although SSL and TLS are nice to have, you should by no means rely upon them to ensure the security of your update system. (See also the "Certificate Authority Compromise" box.)
Attacking Update Systems
What exactly then do you need to protect against in an update system? The obvious candidates are malicious modification of software on the fly or the insertion of a new version that includes malicious code that is then uploaded to the server providing the software. However, other less obvious attacks must be dealt with. The first attack to prevent (and one of the hardest) is where an attacker can effectively man-in-the-middle the victim and prevent connections to the update server. This is tough, because basically the update server can do nothing to block or prevent it.
On the client side, the only thing you can really do is make sure the software notifies the user that something is going on (e.g., "Unable to reach update server, it's been a few days, something bad might be going on"). The victim can then take action, such as connecting through a different network or using a VPN to get the updates.
Related attacks are slow-down attacks or endless data attacks. In this case, the attacker can cause the update connection to slow down so that the update trickles through very slowly. For software of any size, this is the same as a blocked network attack, but with the added benefit that the victim might not be notified (because the update is working and being downloaded). Again, the only thing you can really do here is have the client software notify the victim so they can take corrective action.
Another major way to attack software updates is by convincing a victim's system to install an older version of the software, because the old version is properly signed and includes a now-known security flaw that the attacker can exploit. The best way to deal with this is to have the client software keep track of what version is installed and refuse to install older versions unless forced – sometimes broken updates are shipped, and not giving people the ability to rollback is not fun. Thus, the client software needs to be somewhat intelligent to spot problems like rollback attacks, slow network attacks, or blocked network attacks.
Attackers also can attack an update system by compromising the update server and removing update files. In this case, the client connects and checks for a newer version, but nothing exists, so obviously everything is OK. To deal with this, the server must include metadata about the software (e.g., the current version, whether this is a security update, etc.). You will then need to protect this metadata, too. Although it is separate from the software, it needs to be protected just as well as the software, so you need a lot of strong cryptographic signing and secure key management to support all of these things.
Vendor-Supplied Update Systems
What's the easiest way to build a secure update system? You don't because you can easily piggyback onto an existing vendor. The advantage here is that you can get updates to clients securely. The disadvantage is you need to build packages and upload them to each vendor you want to support (Fedora, EPEL, Debian, etc.). This process can work if you're willing to support only a limited number of client systems, and it is especially suitable for non-profit open source software. In the open source world, the majority of vendors provide a relatively easy way to get your software into their repositories (the more the merrier, right?).
Buy this article as PDF
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.