Understanding AIR Security

1
Understanding AIR Security
Robert Munn President, Emergent Path
2
Overview

• The AIR Security Model
• Application Installation
• Application Sandbox
• Non-application Sandbox
• Sandbox Bridge
• Encrypted Local Storage
• SQLite Considerations
• Updating AIR apps
• Moving from the Web to the Desktop

1
3
AIR Security Model

• Consists of Flash Player Security Model plus AIR
  Sandboxes
• Some functions typical of Web apps are restricted
  (dynamic code generation)?
• Installation via public Certificate Authorities
  (Verisign, Thawte)?
• Only code in application sandbox has full access
  to AIR API set
• Sandboxes may use sandbox bridge to communicate
  with each other

4
AIR Security Model
5
Application Installation

• Remote and local file install supported
• Requires signed certificate
• Developers can self-sign certificates
• Enterprises can self-sign certificates for
  internal applications
• Thawte and Verisign are the current trusted
  public CA's
• If you sign an initial application with a
  specific certificate, new versions must use the
  same certificate

6
AIR Sandboxes

• Application fully privileged
• Remote per remote domain, runs with Flash
  Player security model
• Local Trusted Has access to local system and
  remote systems, but not full AIR APIs
• Local with Networking Has access to remote
  sites but not local system
• Local with File system Has access to local
  system but not remote sites
• http//www.adobe.com/go/flashCS3_progAS3_security

7
AIR Sandboxes
8
Application Sandbox

• Files installed with the AIR installer file go
  into an AIR application directory
• These files run in the application sandbox with
  full privileges to the AIR API's
• Other sandboxes may interact with files in the
  application sandbox via a sandbox bridge
• Take care when exposing privileged functions to
  non-application sandboxes through the sandbox
  bridge

9
Remote Sandbox

• Files loaded from Internet URLs
• Runs with the privileges of Flash Player
• Separate remote sandboxes per network domain
• No access to local system
• No cross-domain access

10
Local Trusted Sandbox

• Files loaded from the local system
• User must designate these files as trusted using
  Settings Manager or Flash Player trust
  configuration file
• Access to remote domains and local system
• Does not have full set of AIR privileges

11
Local With Networking Sandbox

• Local SWF published with networking designation,
  but has not been trusted by user
• Can communicate with remote domains but not local
  system
• Only available to SWF content

12
Local With File System Sandbox

• Local scripting file not published with
  networking designation and not explicitly trusted
  by user
• Includes JS files that have not been trusted
• Has access to local system but not remote domains

13
Sandbox Bridge

• Provides communication link between sandboxes
• Can provide a means for cross-domain scripting
• Think carefully about exposing privileged methods
  from the application sandbox to remote sandboxes
• parentSandboxBridge and childSandboxBridge
• Objects are passed by value

14
Local Storage

• Files and data stored in clear text can be read
  by any local process with permissions on the
  directory/file where the data is stored
• AIR provides encrypted local storage for secure
  storage
• Uses 128-AES encryption
• Stores data in key/value pairs
• Other AS encryption libraries are available
• http//crypto.hurlant.com/

15
SQLite Considerations

• SQLite databases have no built-in security
• Can be read by any application on the system with
  db capability
• Possible solutions
• Encrypt all data in db
• Encrypt db file itself
• Hash db file to create a signature to check
  whether file has changed
• http//probertson.com/articles/2007/06/21/securing
  -air-sql-database/

16
Updating AIR apps

• New versions must use the same certificate as the
  original version
• Guard against downgrade attack by checking for
  updates on application start

17
Moving from the Web to the Desktop

• AIR changes the game for Web developers by
  creating a new trust contract with users
• In traditional Web applications, developers
  ability to write to the local file system is
  limited by the Web browser security model
• Interactions with the local system include
  writing cookies and images
• Such interactions are handled automatically by
  the browser and can be denied by the user
• The security contract with AIR is that the user
  grants the developer unlimited access to the
  local system

18
A New Contract with Users

• AIR apps are trusted local system applications
• The AIR model is one of desktop applications, not
  Web applications
• Security is every developer's responsibility!

19
References

• Flash Player Securityhttp//www.adobe.com/go/flas
  hCS3_progAS3_security
• Introduction to AIR Security http//www.adobe.com
  /devnet/air/articles/introduction_to_air_security.
  html
• "Adobe AIR is out. Let's talk about security."
  http//isc.sans.org/diary.html?storyid4019rss
  Lenny Zeltser, 2/25/08
• "Is Adobe vulnerable to an AIR attack?"
  http//www.infoworld.com/article/07/10/03/Is-Adobe
  -vulnerable-to-an-AIR-attack_1.html Eric Lai,
  Computerworld, October 03, 2007
• State of Security bloghttp//blogs.adobe.com/stat
  eofsecurityLucas Adamsky, Adobe Systems
• AIR Security Livedocs http//livedocs.adobe.com/f
  lex/3/html/help.html?contentsecurity_7.htmlAdobe
  Systems