Curl Blog

2 Posts tagged with the air tag
2

Recently PaloAlto Networks published a survey Social Networking Usage Explodes In Businesses Worldwide that found 27 different social networking applications in use across 95% of the participating organizations.  The survey findings are based on actual analysis of application traffic, not survey questions. The following chart from the report shows that the most prominent use is Instant Messaging at 50%.

Enterprise 2.0 Application Usage

 

The survey makes the point that applications are not threats ? yet they carry risks.

 

"The adoption of Enterprise 2.0 applications is being driven by users, not by IT. The ease with which they can be accessed, combined with the fact that newer (younger) employees are accustomed to using them, points toward a continuation of this trend. The somewhat disconcerting fact is that users do not take into account the business and security risks that these applications present. Looking at the 202 Enterprise 2.0 applications found, 70% can transfer files, 28% are known to propagate malware, and 64% have known vulnerabilities."

 

Enterprise 2.0 Application Characteristics

 

All this points to increased security risks as more enterprise 2.0 applications see more pervasive adoption.  As we have previously pointed out it is important that developers and IT operations both understand best practices with regard to security.  Jeffrey Hammond points out in his paper on Securing Rich Internet Applications that is is important to understand the 3 Attack Surfaces: Server-side, Communication-stream and Client-side.  In this post I'll focus on the client-side. 

 

RIA frameworks use a Sandbox model the protect clients from malicious code.  It is important to realize however that not all sand boxes are created equal.  While Ajax, browser based applications use the browser's sandbox, RIA frameworks like AIR, Silverlight and Curl use their own security model and permit access to the local machine.  It's natural that developers want to take advantage of the broader capabilities at RIA frameworks offer over the browser based sandbox but they need to be aware of how their decisions effect the vulnerabilities that these frameworks introduce.

 

To give administrators and application developers the most control over security for creating and deploying Enterprise 2.0 applications Curl supports both un-privileged and privileged modes executing in the browser and on the desktop.  This is in contrast to AIR that allows only un-privileged in the browser and only privileged on the desktop.  The follow table shows the differences between Curl and AIR privilege options.

Curl Adobe Security Comparison

 

 

Curl Desktop applications use the same security model as Curl applets that run in the browser.  Additionally un-privileged applets can access their own area on the local disk to offer improved performance and a better user experience but present a much lower risk profile   This also means that application developers can write un-privileged applications that make use of local storage and run both in the browser and standalone on the desktop.
2 Comments Permalink
31

Adobe has released their new AIR product with much fanfare about letting developers "[use proven Web technologies to build rich Internet applications that deploy to the desktop and run across operating systems|http://www.adobe.com/products/air/]."  The grand vision that's being promoted is that AIR is pioneering the application development model of the future, where cross-platform applications will be developed using a platform-independent tool such as AIR, and then deployed across the Web as downloadable gadgets that can be installed on any computer.

 

The concept is attractive, but there are several weaknesses in the way AIR implements it.  One of these weaknesses is performance: while the speed of AIR's execution engine may be fine for gadgets, will performance that is still an order of magnitude slower than native code be acceptable for serious applications like Adobe's own Photoshop?  (Note that the recently released Photoshop Express service is not an AIR application; it's a server-side application with a Flex front end.)  A second weakness is the complexity of the AIR execution architecture: will future application developers really find AIR's conglomeration of JavaScript and ActionScript execution engines to be a more tractable development platform than a single, coherent, object-oriented execution environment?  But the weakness I want to address today is AIR's security architecture.

 

Security is a central issue for any mobile code execution platform. When a user loads an application from a server, unless the user is able to verify the authenticity of the application and the trustworthiness of the application's provider, it is only prudent to assume that the application could be malicious.  This is why Web browsers execute the JavaScript on a Web page inside a security sandbox that prevents the script from stealing information or damaging files even if it is malicious.

 

Some advanced mobile code platforms, such as Java and Curl, provide a sandbox for garden-variety untrusted applications, as well as a means for eliminating the sandbox restrictions for applications that a user determines can be trusted.  Since trusted applications will have full access to the user's machine and network, it is very important that their origin can be authenticated.  This is typically done by requiring that a trusted application be digitally signed by its provider, using a certificate issued by a recognized certification authority such as Verisign.  This architecture extends the range of a platform, in a safe way, so it can handle a spectrum of application requirements that includes the features of typical desktop applications, many of which require fuller access than can be granted to an untrusted application running in a sandbox.

 

The designers of AIR obviously wanted to play in the desktop application space, so AIR applications have full access to the machine they are running on.  But it seems that the AIR designers were unwilling to give up on also being a platform for casually loaded Internet gadgets, even though they did not see fit to give AIR a sandbox for running untrusted applications.  The result is a mongrel security architecture that may impose costs on a lot of innocent people over time.

 

In a nod to the authentication requirements for trusted applications, Adobe says that all AIR applications must be signed.  But the nod is an empty gesture, because AIR does not require signatures to be based on a certificate from a recognized certification authority!  If you want, you can create your own certificate out of whole cloth and sign your AIR application with that!  I have to guess that Adobe did this because they didn't want to cut themselves off from the casually loaded Internet gadget domain, and they weren't willing to require that the creators of such gadgets go through the process of obtaining a legitimate certificate.

 

Yes, if an AIR application's certificate is self-signed, AIR displays the publisher as "UNKNOWN", "[giving the user pause as to whether they should continue|http://blogs.adobe.com/stateofsecurity/2008/02/air_security.html]."  But what detective work is the user expected to do?  How many users will actually be able to do it?  It seems more likely that if Adobe's dreams for AIR are realized, a generation of users will be trained in the habit of clicking "Install" for fully privileged AIR applets of unauthenticated provenance.  Adobe has already begun this training program by posting a large number of self-signed AIR applications on the Adobe AIR Marketplace, including the DiggTop feed reader, twhirl Twitter client, and Google Analytics Reporting Suite, just to name a few.

 

The resulting situation will be a bonanza for criminal hackers.  AIR will become the first truly cross-platform tool for distributing malicious applications.  Macintosh and Windows, home and business computers will all be equal-opportunity targets for Trojan horse attacks, keystroke loggers, etc., truly realizing the dream of "write once, hack everywhere!"

 

Adobe can't have it both ways.  Casually loaded Internet gadgets need to run in a security sandbox.  Trusted applications need to be rigorously authenticated.  Adobe needs to stop pretending that their self-signed application model provides a secure basis for running casually loaded applications with full privileges.

31 Comments 0 References Permalink