Trusting your desktop to the web: Safety in Air, Silverlight and Prism
October 29, 2007 § Leave a comment
A few weeks ago, I wrote about the safety of extensions to Web browsers. In the meantime, the landscape of web browsing has changed a lot, at least for developers. Why ? Because of Adobe Air, Microsoft Silverlight and Mozilla Prism, three tools used to put the web on your desktop.
While none of these products is actually new — they are all renamed versions of things that have been hanging out in the air for some time — and none of these products is branded as web browsers, well, that’s exactly what they are. Of course, whenever new browser or browser-like products appear, one of the main questions should be: how safe are they ?
Let’s take a somewhat deeper look.
What is it ?
Air, Silverlight and Prism are branded under many qualifications, from “Ajax desktop integration tools” to “Rich interactive web experience” to “Rich internet applications on the desktop”. In other words, these applications are just web browsers without the buttons. Air is built on top of Adobe Flash and WebKit (the core of Safari and Konqueror), Silverlight is built on top of .Net and — depending on the platform — either Internet Explorer, Firefox or Safari, while Prism is built on top of Gecko (the core of Firefox and Thunderbird). All three products are intended for web developers who want to build desktop applications or to make web pages look and feel like desktop applications.
If this sounds less glamorous than the advertising, it’s perhaps because this kind of things have been around for some time:
- this is the exact premise of Apple’s Dashboard, which has been available for about 2-1/2 years, and is based on Apple’s Safari ;
- before that, this has been the premise of Yahoo! Widgets (née Konfabulator), the inspiration behind Dashboard ;
- before that, this has been one of the driving ideas behind XUL and Gecko themselves, the technology behind Firefox, Thunderbird, Netscape Navigator 6… ;
- still before that, this is quite close to the whole idea of browsers sidebars, as available in just about any browser since at least 2002 ;
- even before that, there was Windows Active Desktop, launched around 1997 and forgotten not much later;
- Windows Active Desktop itself was prompted as a counter-attack to Netscape’s 1996 Constellation / Netcaster — I believe that’s where it all began but I might be wrong.
Now, what is true is that this range of tools will make it much easier for web developers to build desktop applications and will bring some long-needed web controls to desktop developers. While none of the technology is actually new, from the user’s point of view, it might still bring something like a revolution, by blurring even more the barriers between the desktop and the network. Or, in other words “The network is the computer.”
At this point, perhaps I should consider mentioning Sun Microsystem’s JavaFX. JavaFX is marketed essentially as Prism, Air or Silverlight, with essentially the same promises (in this case, under the label “Rich Internet Applications”). However, after a few hours of experimenting with JavaFX, the technology seems totally unrelated. Neither superior nor inferior, just unrelated, except by a marketing ploy. In a few words: it’s Java, with an alternative beginner-friendly syntax, but still using Swing and not sporting anything specially Internet. So it’s out of today’s game.
What’s worst it can do ?
Let’s get one thing out of the way: while I’m going to mention now and then what a developer may do with one tool or with another, what I’m interesting in is not the feature-set but the safety of tools. To which tool should you trust your desktop, if any ? Or, taken from the opposite point of view, what’s the worst that Air-, Silverlight- or Prism-applications can do to you and your computer if you use them for your desktop ?
In this survey, I will not take into account the possibility of bugs in Air, Silverlight or Prism themselves. Rather, I will concentrate on malicious or ill-programmed applications for Air/Silverlight/Prism.
XMLHttpRequest (for interactivity and network communication). To this day, all these technologies are rumored safe for desktop use. Let’s look a bit deeper…
“AIR applications run with the same user privileges as native applications. In general, these privileges allow for broad access to operating system capabilities such as reading and writing files, starting applications, drawing to the screen, communicating with the network, etc. Operating system restrictions that apply to native applications, such as user-specific privileges, equally apply to AIR applications.“
(extract from Air’s documentation)
A few pages further in the documentation, it turns out that the developer may decide to run parts of its application in sandboxes, i.e. without giving them access to the whole operating system, and other parts with all privileges. It is up to the developer to decide how to enforce that security, which parts of the application run in which sandbox, and to make sure that interactions between the sandboxes will not compromise the security of the system.
I haven’t had time to play too much with Air. However, just by reading the documentation, it seems that:
- an Air application can be made to look just like any other application
a malicious Air application can take control of your session and do just as much harm as any other malicious application, which means a lot if you’re under Windows, a bit less under Mac OS X or Linux ;
a malicious Air application can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
if a non-malicious but trivial or well-programmed Air application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, the hijackers could not use this website should not be able to take control of your session
if a non-malicious but complex and ill-programmed Air application depends on a malicious website, this website can inject code in the application and get that application to run the malicious code, hence again taking control of your session
a nice Air application may be automatically upgraded to a not-so-nice Air application by a malicious developer or anyone who takes the control of the developer’s website.
Note that Air contains a few interesting techniques to make life harder for people who may wish to inject code in an Air application from a malicious website. That is, the untrusted world may not execute privileged code unless this code has been made explicitly available by so-called “sandbox bridges.” According to the documentation, other manners of injecting code are forbidden (
innerHTML…). However, if the documentation is to be trusted, these interdictions are way too limited to keep a decided malicious developer at bay: once some data falls into the hands of untrusted code, the untrusted code seems allowed to modify that data at will, which may include changing the behavior of code if that data contains code. It is probably possible to use automatic checking tools (such as customized JSLint or JSTify) to guarantee that this will not happen.
Unsurprisingly, an AIR application is just as dangerous as any other application. More so, in fact, as the security of the application may additionally depend on the security of a distant website.
In addition, my experience with the community of web developers tells me that, at least in a first time, the future community of Air developers will be interested more in features than in safety and will produce a number of unsafe-but-useful libraries that will have time to spread and be commonly used before their weaknesses are understood. The only thing that could limit this would be a comprehensive library of safe code provided with Air. While Air’s standard library contains a number of interesting features, there seems to be no safe code to give access to unsafe features.
Silverlight’s official documentation is lacking and the SDK contains strictly nothing to read. That is, there seems to be more than enough tutorials to help people get started, but technical issues seem mostly non-covered, possibly because people who are expected to understand anything too technical are also presumed to be proficient with .Net and to start digging on .Net. Consequently, the informations presented here have been gathered from around Microsoft’s Developer Library and Shawn Farkas’s blog — Shawn Farkas is one of the developers of Silverlight.
“All applications written for Silverlight are security transparent. This means that they cannot:
- Contain unverifiable code
- Call native code directly
Silverlight applications can access public methods exposed by platform assemblies which are either:
- Security transparent (neither the defining type nor the method has any security attributes)
- Security safe critical (the method has a SecuritySafeCriticalAttribute)
Silverlight applications may contain types which derive from:
- Other types defined in the application
- Unsealed, public, security transparent types and interfaces defined by the platform
Silverlight applications may contain types which override virtual methods and implements interface methods which are:
- Defined in the application itself
- Defined by the platform and are transparent or safe critical”
What this seems to mean is that a Silverlight application may never proceed with any operation that isn’t considered as safe by whoever introduced that operation in the first place. Taken to its logical conclusion, this would mean that no Silverlight application could ever read or modify an arbitrary file. Unfortunately, this is not believable — especially from Microsoft — as this policy would make Silverlight much safer but also much poorer in terms of features than the competition. Therefore, I understand the description to mean that most Silverlight applications will, in fact, be composed of two things: an “application written for Silverlight” (the equivalent of the Air sandboxed code, as seen above) and some code “defined by the platform” (the equivalent or privileged code).
From this conclusion, let’s deduce a few facts:
- a Silverlight application can be made to look just like any other application
- a malicious Silverlight application can take control of your session and do just as much harm as any other malicious application, which means a lot since you’re under Windows ;
- a malicious Silverlight application can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
- if a non-malicious Silverlight application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, or because your network connection has been hijacked, the hijackers could not use this website should not be able to take control of your session (more details on this later)
- if a non-malicious but ill-programmed Silverlight application depends on a website, and this website itself is malicious, it seems that the hijackers could trick your Silverlight application into pretending to be your password manager, etc. (more on this later)
- a nice Silverlight application may be automatically upgraded to a not-so-nice Silverlight application by a malicious developer or anyone who takes the control of the developer’s website.
Again, from Shawn Farkas’s explanations:
“Silverlight applications [...] may only call transparent or safe critical APIs exposed from the platform.”
Among other things, this means, unsurprisingly, that privileged code may be made available for use by untrusted code in much the same way as in Air. The big difference is that it seems impossible for the untrusted code to modify privileged code to execute code containing operations considered unsafe. It still seems that ill-programmed applications could be hijacked by a website into executing code considered safe, though, although with much more difficulty than in Air.
Note the keyword: considered. While it’s nearly certain that any operation that will modify a file on your hard drive is considered unsafe, it seems pretty sure than operation that will only open a new window will be considered safe. Guess what I can do just by opening a new window ? Yes, as usual, I can masquerade as your password manager or your bank account manager, take over your passwords and send them to whoever is behind this.
Unsurprisingly, a Silverlight application is just as dangerous as any other application. Less so than an Air application, despite the complexity of the technologies driving Silverlight, but still more than a regular desktop application, as the security of the application may additionally depend on the security of a distant website.
Silverlight developers do start with two additional advantages, though:
- the safe library provided for them is quite vast, which should limit the appearance of unsafe libraries wrt Air or Prism;
- you have to try slightly harder than in Air if you want to write an unsafe library usable by unprivileged code — it’s still more streamlined than in Prism, though.
For this section, I’ve both worked with the documentation of Prism and discussed with Mark Finkle, his main developer. As these discussions gave me a few hints of where Prism is heading, I’m going to subdivide this section between the situation as it is in the current preview release and what it’s going to be when Prism reaches 1.0.
“Webapp bundles, as defined today, can and usually do include a JS (webapp.js) which runs with system privileges. This should be removed, so that starting a webapp bundle does not imply handing over your machine and all the data on it to whoever created or modified the bundle. Ideally, webapp bundles should not be able to do more than a normal webapp can, just run in a slightly different UI (no menu etc.) and in their own process.“
(source: Prism’s documentation)
In the current state, it seems that:
- a Prism application cannot be made to look just like any other application
- a malicious Prism application may take control of your session and do just as much harm as any other malicious application, which means a lot if you’re under Windows, a bit less under Mac OS X or Linux;
- a malicious Prism application cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number
- if a non-malicious but trivial or well-programmed Prism application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, the hijackers could not use this website to take control of your session
- if a non-malicious but complex and ill-programmed Prism application depends on a malicious website, this website can inject code in the application and get that application to run the malicious code, hence taking control of your session
- a nice Prism application cannot be automatically upgraded to a not-so-nice Prism application by a malicious developer or anyone who takes the control of the developer’s website.
It is possible to make privileged code (the part of the Prism application that gets installed on your hard drive) communicate with untrusted code (the part of the Prism application that resides on the distant server) through messages — the mechanism looks cleaner, less accident-prone and easier to check automatically than in Air but ultimately equivalent. If the data sent between these codes contains code itself, it may be overwritten at will by malicious unprivileged code, which can result in the Prism application, if it’s poorly programmed, being fully hijacked.
Today’s bottom line
Unsurprisingly, a Prism application is just as dangerous as an Air application. Here, also, my experience with the community of web developers tells me that we are going to see unsafe libraries being required for a number of applications, hence opening wide doors for applications hijacking.
As of today, Prism applications suffer from :
- a small library of safe tools ;
- a large library of unsafe tools ;
- the fact that it’s very easy to write unsafe code — well, just as easy as in Air and much more than Silverlight.
As far as security is concerned, the result ends up slightly worse off than Air. However, the story doesn’t stop here.
Prism is evolving a lot. In particular, Mark Finkle insists that, while there is only little security for the current prototype, the upcoming versions will change the situation completely. In fact, there’s a huge difference between the aims of Air, Silverlight and Prism — while that difference is not visible yet, it should become evident with the next prototypes. To summarize, Silverlight and Air are full programming platforms, which means that they attempt to provide developers with all the tools to write any application — with all the unsafety it implies. On the other hand, Prism is a super-bookmark that lets you use a web application in a convenient way, without the clutter of the browser’s user interface. While Silverlight could be conceivably used to write the next Windows Update or Microsoft Word and Air could be conceivably used to write the next Adobe Reader or Acrobat Pro, Prism does not need and does not want such power, rather being designed for the next Google Mail, Google Office or aMSN — the examples come from me, by the way, so don’t try to read Mark Finkle’s mind from this blog entry.
“we want the web application (written in web content) to handle as much as possible – using open web technologies“
(IRC conversation with Mark Finkle — I promise I’m going to stop quoting him)
Technically, this means that Prism applications will lose access to XPCom. The direct consequence will be that web applications should be exactly as safe as the corresponding version of Firefox. Possibly somewhat safer, actually, due to the fact that Prism will be lighter than Firefox.
What follows is the result of a discussion, so don’t take it for guaranteed. From what I gather, in the future :
- a Prism application cannot look just like any other application
- a malicious Prism application cannot take control of your session ;
- a malicious Prism application cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number ;
- a malicious website can theoretically inject code into Prism — but not without the help of Prism ;
- a nice Prism application cannot be automatically upgraded to a not-so-nice Prism application by a malicious developer or anyone who takes the control of the developer’s website.
Privileged code can read and write unprivileged code, working essentially as a pre-processor or, say, GreaseMonkey. There is still a possibility to use this mechanism to inject code from the website to the Prism application, but that looks impossible to do by accident — that is, unless the Prism application has been designed specifically to accept injection, there is little a malicious website could do. It looks quite possible to write a customized JSLint or a JSTify module to automatically detect Prism applications specifically designed to accept injection and reject them.
In other words, out of the box, Prism applications should be completely safe. The price of this safety being that the most complex Air or Silverlight applications will be richer in terms of desktop-side features than Prism. This won’t prevent Prism developers from writing a tool comparable to, say, Microsoft Office, or an application used by your local tax office, but it will prevent them from writing a tool to index files on your hard drive or to edit videos.
Note that Prism itself will support an extension mechanism, which has the potential to change everything in terms of security and features. That is, Prism extensions, just like Firefox extensions, are a mechanism that will allow adding arbitrary features to the whole platform, including anything unsafe. I’ve already discussed the danger of Firefox extensions in a previous blog entry, so I’m not going to repeat myself here. If extensions are taken into account, the safety of Prism is as bad as that of Air or Silverlight. The good point is that, by opposition to what happens in Air or Silverlight, Prism extensions will be clearly separated from Prism applications: the install mechanism will be different and will warn the user about potential dangers of extensions.
Tomorrow’s bottom line
A Prism application that doesn’t rely on extensions should be absolutely safe. The fact that Prism somewhat discourages the installation of extensions is a good point but it may not end up being sufficient to prevent the web developer community from developing a whole bunch of unsafe libraries, eventually leading to a situation equivalent to that of Air.
- a Dashboard widget cannot be made to look just like any other application, as it resides on a different layer
- a malicious Dashboard widget can take control of your session and do just as much harm as any other malicious application ;
- a malicious Dashboard widget cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
- I haven’t been able to assert if a distant website may hijack an ill-programmed Dashboard widget.
Every code in Dashboard is privileged. There is no security involved.
- a Y!H widget can be made to look just like any other application
- a malicious Y!H widget can take control of your session and do just as much harm as any other malicious application ;
- a malicious Y!H widget can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
- I haven’t been able to assert if a distant website may hijack an ill-programmed Y!H widget.
Every code in Y!H is privileged. There is no security involved.
So, should you ?
The question asked in the beginning of this post was whether you could trust your desktop to Air, Silverlight or Prism. Before judging, let’s summarize:
- A randomly downloaded Air application can do anything and masquerade as any other application.
- An Air application you trust could still be hijacked and could be dangerous even if does not contain privileged code.
- A randomly downloaded Silverlight application can do anything and masquerade as any other application.
- A Silverlight application you trust could still be hijacked, although with more difficulty than Air, and could be dangerous, although less so than an Air application.
- A current Prism application can do anything but can’t masquerade as any other application.
- A current Prism application you trust could theoretically be hijacked, although with more difficulty than Air, and could be dangerous, just as Air.
- A future Prism application will only be able to do browser stuff and won’t be able to masquerade as any other application.
- A future Prism application will be nearly impossible to hijack and won’t be dangerous even if hijacked.
- A Prism extension, on the other hand, is just as dangerous as a Silverlight or Air application.
- A randomly downloaded Dashboard widget can do anything but can’t masquerade as any other application.
- A randomly downloaded Yahoo! widget can do anything and can masquerade as any other application.
In other words, at the moment, everything is unsafe.
Now, if you’re the kind of user who doesn’t care about security/only downloads applications from sites you trust very much/is pretty sure that the developers of a given application are both honest and careful, any of these technologies should be acceptable for you and you probably ought to go for the most feature-rich. Silverlight and Dashboard will be the most feature-rich respectively for Windows and MacOS X, while Linux users will be happy with either the current version of Prism, the future versions of Prism with extensions or the equally unsafe gDesklets or SuperKaramba.
If, on the other hand, you’re the kind of user who considers that the Net is a wild place with a few malicious people and lots would-be developers who ought to learn one or two things about security before disseminating their creations, and if you are willing to pass the opportunity to see something cool if it means keeping your system safer, you should stick with future Prism web applications, without extensions. Or, if you can manage to check every Air/Silverlight application and reject those that contain privileged code, you should be ok.
This last comment is not benign, mind you. It’s only a matter of time before tools appear that check Firefox/Prism extensions/Air/Silverlight privileged code and reject anything that doesn’t comply with the way you want your computer to behave. I’m working on what could serve as the base layers of such a tool for extensions and Air, anti-virus writers are bound to do the same thing for Silverlight.