The problem is that when you uninstall an AIR application it doesn’t get rid of the encrypted local store data.

Basically if you want to completely blow away an AIR app you need to go into the “/Users//Library/Application Support/Adobe/AIR/ELS”, find your application based on the id and then blow it away. On Windows it’s “C:\Documents and Settings\\Application Data\Adobe\AIR\ELS” (ELS stands for Encrypted Local Store).

I just saw on the AIR Download page that we’ve released version 1.1, the updated version of the AIR runtime. We’ve fixed a ton of bugs, localized the runtimes to a bunch of languages including French, Spanish, German, Russian, Korean, Japanese, Chinese and a few more. Plus we’ve added some new APIs for developers:

• Support for building internationalized applications, including keyboard input for double-byte languages
• Support for localizing the name and description attributes in the application descriptor file
• Support for localizing error messages, such as SQLError.detailID and SQLError.detailArguments, in the SQLite database
• Addition of Capabilities.languages property to obtain an array of preferred UI languages as set by the operating system
• HTML button labels and default menus, such as context menus and the Mac menu bar, have been localized to all supported languages
• Support for certificate migration from a self-signed application to one that chains to a certificate of authority (CA)
• Support for Microsoft Windows XP Tablet PC Edition and support for 64-bit editions of Windows Vista?? Home Premium, Business, Ultimate, or Enterprise.
• Addition of File.spaceAvailable : API to obtain the amount of disk space available on a disk
• Addition of NativeWindow.supportsTransparency property to determine whether a window can be drawn as transparent by the current operating system
• Bug fixes and memory improvements

A couple of things if you’re planning to start building AIR 1.1 applications with Flex. First, you need to update the SDK which is pretty easy. You also probably want to change the “xmlns” attribute in your application descriptor file to http://ns.adobe.com/air/application/1.1 which will let you take advantage of the performance improvements and the new features. We’ll also be pushing out the latest 1.1 AIR build to users so those people that have downloaded your application should be getting the newest version soon (but your 1.0 applications won’t be affected).

Shu is a new swf2exe wrapper which takes in an AIR application and produces a standalone .exe as a result.

Apparently, it embeds the AIR player so does everything AIR does; it also adds a few additional commands (executing external commands etc.) and support for extension DLLs.

Adobe Systems hopes to make nice with the open-source community and soon deliver a Linux version of its newly released Adobe Integrated Runtime.

Kevin Lynch, chief technology officer at Adobe, said the company is working on a Linux version of AIR, a run-time that lets developers use proven Web technologies to build RIAs (rich Internet applications) that deploy to the desktop and run across operating systems.

Speaking at the Adobe Engage event here Feb. 25, Lynch said that although AIR currently runs on Windows and the Macintosh, “I’m excited about the potential for AIR and Linux working together.” He demonstrated an Intel-based device that ran Windows and Linux, with AIR running on it.

“I think Linux and AIR is a great solution because Linux is a free operating system and AIR is free,” Lynch said.

Moreover, he said he would not be surprised if someone developed an appliance for AIR running on Linux.

Lynch played up Adobe’s interest in open-source technology. Major portions of Adobe AIR, such as the WebKit HTML engine, Tamarin ActionScript Virtual Machine and SQLite local database functionality, are open source, he said.

In addition, Adobe is committed to contributing to the open-source community on multiple fronts, including the release of the free open-source Flex framework and open-source BlazeDS for high-speed data connectivity, as well as active membership in the SQLite Consortium, company officials said.

Lynch said he wants to see AIR in as many places as possible, and Linux is another “very important” target for the AIR run-time. AIR on Linux will come later this year, he said.

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.