Today marks the official release of Adobe AIR, a platform for developing desktop applications using web-based technologies. Let’s see what this tool offers and what security implications it carries.

Adobe AIR (once known as Adobe Apollo) is a run-time environment that bundles several web-enabling technologies and makes them available on the desktop. According to Adobe’s Mike Chambers, Adobe AIR “leverages a number of open source technologies,” including:

•  Tamarin - implements JavaScript/ECMAScript, used in Firefox, Flash
•  SQLite - lightweight database engine
•  WebKit - renders HTML, used by Konqueror browser in KDE and Safari

Adobe AIR allows developers who know how to write traditional web-based applications to use their skills (HTML, AJAX, Flash, etc.) to write local desktop applications. Applications built using Adobe AIR include AOL Top 100 Videos player, eBay Desktop, and NASDAQ Market Replay.

ISC reader Richard Gurley  emailed us a question regarding security concerns associated with the this powerful development platform. Two categories of threat vectors come to mind:

• A malicious Adobe AIR application may act as a trojan and do “bad things” to the victim’s local system.
• A web-style vulnerability (XSS, etc.) in an Adobe AIR application may allow an attacker to target the application’s data or the victim’s local system.

Desktop-Specific Threats of Adobe AIR Applications

The set of first threat vectors is similar across desktop applications that run locally. Adobe implemented sandboxing to limit some actions a local Adobe AIR application. Adobe’s documentation makes it clear that the sandboxes are not meant to mimic the rigorous restrictions of a web browser’s sandbox. Adobe AIR FAQ points out that “applications deployed on Adobe AIR have powerful desktop capabilities and access to local data.”

Adobe AIR applications need to be digitally signed, to assist the end-user in determining whether to trust the application’s author. However, the certificates can be self-signed, and many users will ignore the trust warnings and run even those applications that come from untrusted sources. This is not a new issue, and it is not unique to Adobe AIR.

Ron Schmelzer, an analyst at ZapThink, expressed his concerns with the ability of existing anti-virus tools to protect against rogue Adobe AIR applications in an October 2, 2007, InfoWorld article:

 ” ‘The current generation of spyware, virus, and malware [detection] products have no visibility into running AIR programs,’ Schmelzer wrote in an e-mail. ‘As such, there is a high possibility for malicious AIR applications — which are no longer security-restricted to the browser sandbox and are free to manipulate local machines — to spread into the wild.’ “

I am more optimistic about the ability of existing anti-virus suites to detect improper actions of an Adobe AIR application through behavioral techniques that observe any local programs. Such techniques involve checking for suspicious registry, file system, and network actions that a malicious application would exhibit regardless of the framework within it operates. However, since I have not experimented with Adobe AIR applications, this is purely a hypothetical assessment. (Perhaps those more familiar with inner-workings of anti-virus tools or with Adobe AIR applications would like to comment?)

Web-Specific Threats of Adobe AIR Applications

The other, and perhaps more significant set of threats to consider is tied to those of any web applications. Vulnerabilities in a web application could allow an attacker to launch attacks based on Cross-Site Scripting (XSS), SQL injection, local link injection, and other techniques associated with traditional web applications.

The most interesting security repercussion  of a platform such as Adobe AIR is that it merges traditional web application techniques with the more-permissive security models of local applications. Consider a hypothetical example where an Adobe AIR application allows the user to open and execute a local file. An XSS-style vulnerability in an application could allow a remote attacker to inject a malicious JavaScript into the application that would attempt to execute a local program of the attacker’s choice. This is more difficult to execute when the script runs within the confines of a web browser, than if the script runs within a more permissive sandbox of Adobe AIR.

Adobe’s Lucas Adamski wrote an excellent article describing the Adobe AIR security model. In his write-up, Lucas describes the two sandboxes implemented by Adobe AIR and outlines the security risks that the developers of Adobe AIR applications need to consider. He also points to the security documentation Adobe wrote to assist developers in addressing some of these challenges. Lucas highlights the need for developers to follow Adobe’s security recommendations to create resilient applications:

” However, the privileges inherent in a full desktop application mean the developer can sometimes find ways around these restrictions. The reality is that doing so will almost certainly introduce a large amount of security risk into the application and for the end users of the application. Thus Adobe strongly recommends that developers stay within the restrictions placed by the AIR security model, and carefully consider the cost of implementing rigorous security mitigations for bypassing them. In most cases the development cost of these mitigations will significantly exceed the cost of finding an alternative solution that stays within the bounds of the security model. “

Undoubtedly, many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end-users to attacks. Will our destkop lock-down practices and anti-virus tools compensate for such conditions? I hope the answer is “yes,” but I suppose only time will tell.