I took a look at the native side of the code, which is written in C# and compiled smoothly in Visual Studio 2008. The concept is simple. Instead of launching an AIR application directly, you start the “Command Proxy” application. The Command Proxy launches the AIR application, passing a port number and optionally an authorization string. Next, the Command Proxy creates a TCP socket which listens on the specified port. The AIR application can then use its socket API to send commands to the Command Proxy, which is outside the AIR sandbox.
The communication channel between the command proxy and AIR application looks like a potential vulnerability. One of the things application developers should worry about with security is insecure cross-process communication mechanisms hanging around on someone’s machine. For example if a process listens on a named pipe, and that named pipe has no ACLs and no validation of inbound communication, the process is vulnerable to all kinds of attacks when garbage is sent down the pipe. In the example on using the command proxy how do you secure it so that it doesn’t turn into a general purpose process launcher?
Barnes has an obvious incentive to cast doubt on AIR solutions (he’s a Microsoft RIA
Silverlight evangelist), but nevertheless this is a good debate to have. How difficult is it to do this in a secure manner? It is also interesting to note the opening remarks in Chambers’ post:
Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.
This is really one feature: access to native code. I remain somewhat perplexed by AIR in this respect. Is the inability to call native code a security feature, or a way of promoting cross-platform purity, or simply a feature on the to-do list? I don’t think it is really a security feature, since AIR applications have the same access to the file system as the user. This means they can execute native code, just not immediately. For example, an AIR app could download an executable and pop it into the user’s startup folder on Windows. That being the case, why not follow Java’s lead and provide a clean mechanism for calling native code? Adobe could add the usual obligatory warnings about how this breaks cross-platform compatibility and so on.