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.)

Certificate Authority Compromise

In December 2013, Google detected a subset of French government users being given abnormal SSL certificates for Google websites [10]. Chrome includes internal protections for verifying Google website certificates now, so even if the new certificate was properly signed (as these were), it will be detected and possibly reported to Google, depending on your settings. As it turns out, the French CA, ANSSI, sold certificates that could be used to sign any domain, for use with HTTPS intercepting proxy servers. Although this is a legitimate use, these certificates can be used to attack anyone on the Internet using any SSL-protected website. I suspect this event will lead to increased effort on things like SSL certificate pinning and the use of DNSSEC to add additional security to the SSL certificate verification process.

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

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News