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.

6 Responses to Application Update Security and Native Application Installers

  1. suntzu says:

    Will air2 be coming with an air2 updater example?It would be nice if Adobe could release a template (demo updater) for writing updater for adobe air2. Ideally a developer would want an abstraction so that they don’t repeat security mistakes while writing an updater for air2[No, it will not. It’s a good idea, but it didn’t make the cut. —Oliver]

  2. Huuuze says:

    When will we be able to demo the installer functionality? My understanding is that this will be available in a future release of Flash Builder. It’s one thing to inform the community about this feature, but if we’re not able to take it for a test run, what good is it?[Although this functionality is not yet available in Flash Builder, it is already available in the beta release of AIR 2. —Oliver]

  3. After reading this message, I have a few questions.1) Our main interest in .dmg/.exe for distribution isn’t so much to bundle native components, as it is simply to have another easy-to-use path for users to install our application. If we package a .air file into .dmg/.exe, with no other native components, is it still possible to use the AIR auto-update API to update our application?[No, the Updater is not available for use with native application installers. —Oliver]2) If the answer to question (1) is “No”, what happens if an AIR application packaged as a .dmg/.exe makes a call to ApplicationUpdater.checkNow()? Does it silently fail, or throw an exception? Would we need to conditionally handle this case in order to build our AIR app in both .air versions (distributed through the seamless install badge) and .dmg/.exe?[Off-hand I’m not sure how the ApplicationUpdater framework handles this case. However, you can easily check which mode you’re in by looking at the value of the new Updater.isSupported property. —Oliver]3) If the user installs an AIR application via .dmg/.exe, is it possible to launch the application from the seamless install badge on a web page? Currently, a sizable proportion of our customer base uses the seamless install badge on our website in order to find and launch our application, and we would like to retain this functionality.[No, the seamless install badge also does not work with native application installers. —Oliver]Thanks in advance.

  4. suntzu says:

    Thanks for clarification Oliver. For reference, here is a link which touches the updater issue for air2 apps . Air 2 is very impressive with the goodies it provide out of the box. Without such a piece it would become an issue in adopting air2 platform. As an app developer I am lost now. Updater is a critical use case of desktop applications specially for new applications (since they are evolving and would require frequent updates). It would be great if adobe can provide guidelines or recommendations for writing an updater for air 2 apps. Maybe an example updater would give a head starts to air2 app developers.

  5. you says:

    About your (b) approches to solve the problem, how can we sign the download file and validate it before running ? this is realy a big issue, I really don’t understand why the Updater API can handle this without pissing people off !

    [One option is to use the technique Christian Cantrell describes in this article on signing plugins. That said, I agree this is a difficult problem and one we’ve failed to provide a straightforward solution for. I encourage you to provide your feedback on that point on the Adobe AIR Ideas site. —Oliver]