Archive for January, 2010

Application Update Security and Native Application Installers

New to AIR 2 is the ability to create native application installers. By “native”, we mean that the installers are not .air files, which the desktop operating systems don’t inherently understand, but instead types they do understand: .exe, .dmg, .rpm, .deb.

Applications deployed via native installers do not have access to the Updater API, which is designed to work only with .air files. This is not as restrictive as it might seem, as an AIR 2 application deployed via a native installers has all the facilities it needs to download and launch its own updater.

Applications that take this approach must also take care to secure the download of the update itself. This is handled for you when using .air files and the Updater API. The .air file is signed, and signature validation is performed during the install. None of the contents of the .air file can be executed until after the signature is validated.

The situation is quite different for native application installers: They can generally execute code before signature validation, and may not even be signed. It is therefore critical to make sure that the update you’ve download is valid before opening it. Otherwise, you’ll have created a mechanism that can be hijacked to download and execute arbitrary code.

There are two basic approaches you can use to secure the download path: (a) use an https: download, or (b) sign the download and validate before running. The former is likely easier to set up, but the latter scales better for download support.

If you deploy your application via a native application installer, please take the time to make sure you have a functional, secure update mechanism in place.

Update Strategies for Changing Certificates

As mentioned in my previous post, switching signatures by applying a second signature is a fact of life for updating AIR applications. If you’re creating such an update to your application each time you get a new certificate, then you’ve solved half of the problem. The other half is to make sure you’ve implemented a matching update strategy in your application.

Unlike the signing half, there’s no requirement that each installed application be updated on a regular basis. This would be impossible to enforce, anyway: If a user takes their machine offline for two years, there’s little to be done. To successfully install updates over time, however, you do need to insure that the sequence of updates installed on any given machine includes one update for each certificate transition.

For example, suppose you’ve run through three certificates: C1, C2, and C3. You’ve got a user who has an older copy of your application signed with C1. To update them to the latest version signed with C3, you need to install two updates on their machine:

  1. An update making the transition from C1 to C2
  2. An update making the transition from C2 to C3

It’d be more convenient to create an update straight from C1 to C3 but, in a typical case, C1 will be long expired before you obtain C3 and therefore not useable for this purpose.

Since you can’t assume the jump from whatever version the user has to the latest version is possible, your update mechanism must provide a method of sequencing updates. That can be as simple as changing the URL used to fetch updates each time you change certificates.

This does not mean you need to have users apply all updates to your application, one by one. For example, suppose you issued three updates to your application after acquiring C2 but while C1 was still useable for applying the second signature: Then you can sign each update twice and any user with a version signed by C1 can jump straight to the latest version signed by C2. Again, what they can’t do is jump to any later version that doesn’t have the second C1 signature.

In conjunction with regular updates, an appropriate update strategy will keep application updates a seamless experience for your users.

Update Your Application Regularly

AIR includes an easy-to-use API via which applications can update themselves, and many developers issue frequent updates to their applications. This is not just a good idea: issuing an update at least once each time you renew (or change) your certificate is necessary to maintain the ability to update your application at all.

The issue arises because most code signing certificates are only valid for a limited period of time. (Certificates have to have a limited lifespan in order to keep them secure. The typical lifespan is one year.) Once a certificate has expired, AIR no longer permits it to be used to issue updates to an application. A new certificate has to be acquired, whether as a renewal or as a new purchase.

To secure the transition between those two certificates, at least one update to the application needs to be signed with both certificates, old and new. To facilitate this, AIR does allow the old certificate to be used (for this purpose only) for up to 180 days past its expiration date. In order to issue an update to your application, you must create an update to your application during this period in which both the old and new certificates are valid.

If you fail to create an update signed with both certificates you’ll find yourself unable to update the previous version of your application. You can still have users go through a manual uninstall/reinstall process–basically, uninstalling the old application and installing a new one in its place–but that’s clearly not as desirable.

To keep this all working smoothly:

  1. Replace your code signing certificate when it expires.
  2. Immediately create an update to your application, signed with both old and new certificates, after receiving your new certificate.

Note that you don’t necessarily have to publish the update you create each year, at least not right away. You might wait for a planned product release a month or two later, and apply both signatures to that update as well. Creating the update gives you a backup should you need it. More on this in my next post.

API Tip: Don’t Abuse File.applicationStorageDirectory

It was recently pointed out to me that some applications, which shall remain nameless here, are using File.applicationStorageDirectory to cache hundreds of megabytes of files. Please, don’t do this.

The File.applicationStorageDirectory property is intended to provide applications with a guaranteed writable, unique location in which they can save important information, regardless of which platform they’re running on. The information is saved to locations that are, on typical machines, backed up. On Windows, it’s saved under “<user>/Application Data”, which also roams with the user, if roaming profiles are enabled. There’s an implicit assumption here that the amount of data being stored is relatively small–megabytes at most.

Large sets of cached files should be stored elsewhere, in locations that aren’t backed up and don’t roam. AIR doesn’t include a handy property for finding such a location, but don’t let that stop you; the filesystem API lets you access any location on disk, after all. On Windows, you can use the “<user>\Local Settings\Application Data” directory (note the “Local Settings”); on Mac OS, use “<user>/Library/Caches”.