Adobe AIR security concerns

Adobe’s Paul Robertson has a thoughtful response to my complaint about AIR security. The point I made is that any AIR application has the same access to the file system as the user. This includes local SQLite databases as well as other documents. Robertson’s response:

In order for a user to access an AIR application, he or she must first choose to install the application, including going through a security dialog that will describe whether the application was signed with a security certificate. In this way, an AIR application is comparable to any other desktop application, such as one written in C++. Since any C++ application could theoretically include the SQLite library, installing an AIR application is no different from installing any C++ application in the sense that, by doing so, a user opens himself up to possible abuses and security risks.

The security risks of desktop apps are well-known, and that’s why users have learned to be cautious about installing them. A possible concern though is that Adobe wants to make installing AIR applications really easy. Here’s the description in the docs for seamless install:

The seamless install feature lets you provide a link in a web page that lets the user install an AIR application by simply clicking the link. If the AIR runtime is not installed, the user is given the option to install it. The seamless install feature also lets users install the AIR application without downloading the AIR file to their machine.

I’ve seen how much kids love playing Flash games on the Web. Some of these games would be a natural fit for AIR: play the game from a desktop shortcut, option to save your game locally, no browser baggage. What if a lot of these games turn into AIR apps? Suddenly, instead of online Flash games being relatively safe, they become relatively risky. If users become complacent about passing the AIR install dialog, then all the bad guy needs to do is to create a whizzy game that does a background search of your computer looking for online banking passwords.

The risks will be mitigated if Adobe restricts AIR to signed applications. That’s not the case with the beta:

A further point is that despite the scary dialog, AIR apps are actually tightly locked down from a developer perspective, with no access to native code such as the operating system API, scripts, or native dynamic libraries. While that’s good in one way, it’s arguably the worst of both worlds: not secure (because of full file system access), and not extensible either.

The appearance of the words “System Access: UNRESTRICTED” in the above dialog suggests that Adobe has or is planning a richer security model. If the default were no file I/O, or file I/O isolated to the source domain of the AIR application, that would help considerably. Add compulsory application signing and it would look better still.

I’ll add that I’m most impressed with Paul Robertson’s willingness to enter into this dialog. I wish other software vendors were equally responsive. AIR is in beta so there’s time to fix problems.

Technorati tags: , ,

 

VN:F [1.9.18_1163]
Rate this post
Rating: 10.0/10 (2 votes cast)
Adobe AIR security concerns, 10.0 out of 10 based on 2 ratings

Related posts:

  1. Cross-platform concerns as Adobe abandons AIR for Linux
  2. Adobe Acrobat X puts the focus on security and usability
  3. Amazon fails to address interoperability concerns; Flexiscale plans cloud platform
  4. Cenzic web app report highlights security problems
  5. Security errors when developing for Windows Mobile

6 comments to Adobe AIR security concerns

  • Yes, the ability for Flash or Ajax to read and write the local file system is a significant beyond-the-browser ability. I do not expect people to install Adobe Integrated Runtime applications as casually as they would click a link to go to a new webpage. Browsers will remain uniquely valuable when visiting strangers.

    The security restraints have not been fully set in the current beta… here’s the current situation:
    http://labs.adobe.com/wiki/index.php/AIR:Developer_FAQ#What_security_model_does_the_Adobe_AIR_runtime_provide.3F

    The issues you raise are valid ones, and the team here has had these explicitly in mind the past few months. When the release goes 1.0 it’d be great if you could provide a reality-check then too, thanks.

    jd/adobe

  • This has been discussed at many a place since the alpha and while I know Adobe doesn’t care to be compared to commercial wrappers, nor does it even aspire to, the distribution of the end product AIR creates exactly mirrors a model that already exists (ZINC, SWF Studio, SWFKit Pro, Mprojector, SwishStudio, etc).

    Comparing an online Flash game to an offline one assumes a lot of factors that aren’t applicable. I can’t chance upon a desktop application…I can only choose to download it from somewhere and install it with free will (I can’t be redirected to one or have it unintentionally forced upon me with creative browser commands). In this respect the rules that apply to all downloadable applications (whether AIR or not) apply here as well. Common sense dictates you only download from trusted sources.

    The fact AIR right now has limited access to the OS isn’t really a debit in this regard…it’s actually smart while in beta so they can work out how it will differ from the way commercial wrappers handle things now (and there is a huge userbase of people cranking out desktop apps with far more OS access than AIR offers right now….with no catastrophic worldwide outbreaks of attacks by malicious code I might add) and what level of access they choose to allow. I do think they need to mirror the options offered by the existing commercial wrappers because if they don’t, at least how it relates to desktop RIA’s based on Flash/Flex content, they will cut their own throat limiting their platform by rules of engagement not respected (nor abused in large numbers) by their competitors. If a user wishes to put out malicious code, they will…no matter the platform….this isn’t specific to AIR nor more susceptible to AIR. The question is…with a distribution model that cannot be compared to a web delivered one, what avenue would they have for distribution in today’s world? Surely not any shareware repository…it would get reported too fast. They would be limited to distribution via personal means (self served as a download from their domain) and the word would get out quickly that their code is malicious should they choose become a developer that has “creating havoc” on his/her mind.

    We need to quit pretending that AIR invented the ability to create desktop applications with the benefit of a lower level language encompassed by a higher level one and they need to stay focused on how it will differ from these existing applications (with dedicated runtimes, dedicated html engines, internal DB handling and etc for example) and ignore the stabs at security and other supposed flaws by people that tend to…in fact…pretend they did invent it.

    I personally think (I wrote about this at an earlier date) that scary install splash screen you mention is being done on purpose. To me it simply negates any worries that users will jump the gun and begin commercial distribution of anything AIR based until it at least hits final version 1. I sure wouldn’t (imagine the look on a clients face when they see that). If I had to guess it’s that way for a reason and will not look anything like that when it’s all said and done. :)

    Chris

  • Alan Karp

    The simple way to protect yourself from AIR and other applications is to use the Windows runAs facility to launch the application in a restricted user account. I routinely do that with my browser. Applications run this way don’t have access to my stuff. If the account gets corrupted, I can just throw it away and create a new one.

  • The following file access restriction should be broad enough to allow almost any legitimate application, and safe enough to prevent malware:

    The application should be able to access its initially empty home directory at will, and should be able to access any file that the user has selected from a file open dialog controlled by the Adobe AIR runtime and displayed in fashion that shows its relationship to the particular AIR appliction.

    Similarly for access to anything sensitive – only through dialogs whose appearance and behavior is controlled by the runtime, not the particular application.

  • Mike

    @Chris:

    In fact, there have been worldwide outbreaks of attacks by malicious code.

    You said: “Common sense dictates you only download from trusted sources” and common sense also dictates you don’t double click an unexpected attachment called ‘Love-Letter-For-You.txt.vbs’. But many did and the outbreak of the “I Love You-virus” was a fact.
    ———-
    @Alan

    Yes, _we_ know that, but does your 11 year old nephew know that?
    ———-

    This post actually raises an excellent point, and it’s not about technology, it’s about perception. Flash games are extremely popular time wasters. They _will_ be extended with offline capabilities through Air (like playing on a laptop and later synchronizing high scores, or extrra down loadable levels/characters). At this point, Air applications will be perceived to be relatively save, and many users will click Yes to the ‘scary’ dialog.

  • Sean

    I found this article after installing AIR and then going to install Kuler. While I do have reasonable trust for Adobe here, I did click cancel instead of install. It seemed like a big fat hole in the thought process.

    I don’t want applications mining my personal documents.