Posts in Category "Desktop Security"

Sanboxes in AIR

Posted on February 27, 2008 by Kyle Randolph | Comments (0)

Some interesting questions have been raised regarding sandboxing in AIR, and whether the AIR Application sandbox is “weaker” than the equivalent browser sandbox.

On the face of this, this seems like a reasonable assumption to make. Simply adding system access to a browser sandbox would indeed be much scarier, but that is not what happened. In fact, AIR Application sandbox is significantly different from a browser sandbox insofar that many high-risk APIs have been disabled or severely restricted, making it far more difficult to attack such applications. So the AIR sandbox is not weaker than a browser sandbox; it is different, and in many respects stronger.

Continue reading…

AIR Security

Posted on February 26, 2008 by Kyle Randolph | Comments (2)

We just shipped Adobe AIR 1.0, check it out at http://www.adobe.com/products/air!

AIR lets web developers–whether HTML/AJAX, Flex or Flash–build rich and complex applications that run on the desktop. From a security standpoint, the “desktop” part of that is the key.

If you come from a web development background, you find that desktop applications differ significantly security-wise from apps based in the web browser. Desktop applications have direct access to the local system (insofar that the operating system permits, of course), but in return they must be explicitly installed by the user or system administrator.

Continue reading…

HTML Security in AIR

Posted on October 1, 2007 by Kyle Randolph | Comments (2)

I haven’t posted anything for a bit, as we’ve been very busy in the kitchen! We have a new Beta of AIR available, just in time for MAX. Check it out at http://labs.adobe.com/technologies/air/

My focus for this AIR beta has been HTML security. In AIR, you can build applications in just Flash, or HTML, or a combination of the two. The unique challenges of current design and implementation patterns in AJAX make HTML an especially interesting platform for desktop applications from a security perspective.

Already risky patterns, such as rendering of untrusted content in innerHTML, eval() of remote script & JSON data, and reliance on javascript: URIs, become more dangerous when they intersect with the system privileges inherent in AIR. To address the threats resulting from this model, we have separated application content into two sandboxes.

Continue reading…

AIR Install Experience

Posted on July 30, 2007 by Kyle Randolph | Comments (1)

If you haven’t gotten your personal dose of AIR yet, check it out at http://labs.adobe.com/technologies/air/

The install experience for an AIR application has been the subject of much effort internally, and many questions externally. One of the common questions revolves around the relatively “scary” nature of the installation dialogs.

One of the goals of the installation experience is to accurately communicate to the user the potential risk of installing AIR applications in general. An AIR application is a fully privileged local application, with similar powers and risks to a native application–including full filesystem read/write access. As such, the danger is that developers, IT administrators, or users could assume that AIR applications are somehow intrinsically “safer” to install since they are based upon web technologies.

One way a developer can improve the installation experience for the user is to sign the AIR installer file with a commercial code signing certificate. To see the difference in the installation experience for such an application, check out the “Employee Directory” sample AIR application here: http://labs.adobe.com/technologies/air/samples/

In the future there may also be more restrictive sandbox types that provide a “safer” type of AIR application, with a corresponding installation experience to encourage developers to develop applications with the minimum level of necessary privilege.

Scheming

Posted on July 8, 2007 by Kyle Randolph | Comments (1)

In the realm of security, “trust” is generally defined as “something acting the way you expect it to act.” By that definition, URI schemes (http://en.wikipedia.org/wiki/URI_scheme) have a checkered history at best.

Many developers tend to assume that a URL simply refers to a network data loading protocol, such as HTTP, HTTPS, and FTP. However, it been extended over time to include:
- local file I/O (file:)
- network file I/O (smb:, nfs:)
- local application integration (mailto:, various IM & streaming media schemes)
- local operating system integration (generally very dangerous stuff like shell:, vshelp:, local:)
- actual code generation/injection schemes that can create JavaScript within the browser (javascript:, data:).

Flash in particular also supports the asfunction: scheme, which can be used to call local ActionScript functions within your SWF.

If you are building an application that handles URLs, you should be aware of your responsibility to ensure that any URLs that are passed to the application and acted upon–either by having the application loading it directly or by the user clicking on it–are handled appropriately.

Continue reading…