Silverlight 4’s COM+ Automation Raises Security and Portability Concerns

Posted by Abel Avram on Feb 09, 2010

Sections

Development,

Architecture & Design

Topics

Security ,

Silverlight ,

Rich Internet Apps ,

.NET

Tags

COM

Silverlight 4 supports COM+ Automation when running as an Out-Of-Browser (OOB) application with elevated privileges. Microsoft indicated that this support is a result of enterprise customers requesting such a feature, offering as an example Office automation from Silverlight.

Justin Angel, Silverlight PM, has detailed recently how to set up a Silverlight application to use COM+ (note: link requires Silverlight). COM+ Automation works only for OOB Silverlight applications with elevated trust. Unlike full trust, elevated trust means one can perform almost all commands on a Windows computer with some limitations. For example, one can read/write to the file system but only to “My” folders, i.e. My Documents, My Videos, My Pictures, etc. A list of what Silverlight 4 can do via COM+ includes:

• Running commands or exe files
• Reading the registry
• Accessing the local ODBC
• Reading/writing to disk (with the limitations mentioned above)
• Automating Office

Since many have considered Silverlight as another Flash player, a plug-in with limited access to the computer it is running on, letting it access COM+ has raised eyebrows. On one hand it raises security issues, and on another hand it breaks the portability to other platforms. Several developers commented on the WPF Disciples group:

Shawn Wildermuth: I can't argue with that logic. I understand why MS did this, but I still think it's a mess. COM being Windows only is a bad idea to the platform IMHO.

Marlon Grech, Microsoft MVP for Client App: Although I do agree with Shawn that adding COM+ to SL was a slap in the face to the cross-platform, write once run everywhere proposition. Even if they do add support for AppleScript, you’ll still have a spaghetti code nightmare. On the other hand… guns aren’t bad, it’s the people who use them. Right? ;-)

Jeremiah Morrill: The main *conceptual *security issue I see is that this is a mixture of "trust levels". The CoreCLR is still *not *in* full trust* mode, but any COM instance, by definition, runs outside the sandbox. I think this can be confusing to both developers and users who expect/assume one thing, but get another...which generally isn't good when you are talking about security.

COM+ Automation and running Silverlight applications at elevated trust is not considered a security issue by some because the user needs to make an install to run an OOB application and they are visibly warned that the application is going to access their hard drive. In theory, this comes down to running a desktop application like any other - however, the fear likely comes from the fact that Silverlight was supposed to be an absolutely secure browser application running in a sandbox, not a desktop application.

The other problem is portability. What is it going to happen to this feature on Mac which lacks COM+? Angel mentioned that Microsoft is investigating the possibility of supporting COM on Mac through AppleScript, adding that “if Microsoft chooses to not go ahead with Mac support in Silverlight 4 RTM, well, it’s not because they couldn’t”. As for Moonlight, Angel said:

Moonlight has had the superior security model since it first shipped. Mono supports hosting Moonlight in a GtkWidget that has full-trust capabilities. So while Silverlight has an elevated privileges model, Mono has a full trust model.

In the meantime, system administrators can configure their systems to prevent users from installing and running OOB applications that require elevated trust. Group Policy Settings offers more information on that.

1. Back to top

   COM+ IS SAFE

   by jose fajardo

   I want to just clarify that Silverlight 4 IS SAFE!
   
   IMPORTANT: Even if the usr is an admin, a Silverlight 4 Elevated app does NOT have the ability to elevate to perform administrative tasks.
   
   There is no way the silverlight app can perform admin tasks like writing to c:\ or writing to the registry.
   
   It may appear when your developing that you can indeed break this security rules BUT in the deployed app when a client runs it they WILL NOT BE ABLE TO DO ADMIN TASKS.
   
   [If people can actually do this in deployed silverlight apps then that is a huge bug and MS should be told and im sure they will fix it]

   Reply

2. Back to top

   Re: COM+ IS SAFE

   by Stefan Wenig

   Do you have a source for that claim? It seems highly unlogical that an OOB app should be able to start .exe programs or remote-control office, but have no way to escape some sandbox.

   Reply

3. Back to top

   This was indeed a highly requested feature

   by Stefan Wenig

   Just imagine any app that wants to have some degree of desktop integration (Office, local files, scanner, etc.)
   
   A fully portable app is unlikely to be able to provide this - unless someone builds platform-independent abstraction layers for exactly these tasks. So with SL4 you at least have a chance to provide that support. For other platforms, and for Windows scenario without explicit install, it's quite easy to provide a less integrated experience without sacrificing the features of the windows version.
   
   Face it: This is for enterprises that already have platform lock-in. They will have no immediate problem not supporting these features on other clients, but they can easily create a code base that's largely portable, where only some integration function on the outer border would be disabled with a platform change. What's more, it should be easy to package these functions away so that they can easily replaced with similar functionality in Moonlight. It's all a matter of good design.
   
   No one in their right mind would create an actual internet app that depends on this feature. We're past those times, but it seems the fears are still there.
   
   BTW, I followed this feature, and it's definately something that was created due to customer demand.
   
   That said, I would have prefered a route that allows execution of Silverlight UI code in normal .NET apps (Desktop CLR). That would have made a much cleaner separation between Web apps and locally installed apps. It would still be possible to maintain a common codebase betwenn the two, but installed apps would suffer even less restrictions than SL4 OOB apps (e.g. local data storage via ADO.NET).

   Reply

4. Back to top

   I don't get it

   by Francois Ward

   You know, this thing confuses me. Originally, Silverlight was WPF/E, a subset of WPF, inspired loosely by XBAP's ability to run in a browser, which then begged for some cross platform capabilities. Thus WPF/E was born, and through marketing, eventually, Silverlight.
   
   Now, if you have a browser based/distributed app that will run in a semi-sandbox but still have access to Windows-only features...why the hell are you not using ClickOnce or XBAP? What is the -point- of using Silverlight, when Silverlight's primary point, and reason to live beyond WPF, was cross platform, sandboxed, nearly Flash-like applications?

   Reply

5. Back to top

   Re: I don't get it

   by Stefan Wenig

   If your app absolutely depends on the features you'd use COM+ for, there's not really a point. You might as well use WPF.
   
   But in many cases the COM+ features will just be nice to have. Productivity features that are not essential to the app. Also, you could reimplement those parts natively in Moonlight (or Apple script on SL if that turns out to be supported)

   Reply

6. Back to top

   COM+ for dummies?

   by Sue Leitner

   Hi, when I googled "COM+ Security Issues", this was pretty much the only English language hit. I am just a schlub who had a small business wiped out by security issues that I have been convinced for four years is connected to COM+.
   
   If you are the moderator of this blog and can suggest a better place to put this post, please do. Is there a place where I can post some of my most convincing collections of log files, registry keys, screen shots and naturalist notes for examination by those more knowledgeable than I about the inner workings of COM+?
   
   I am trying my best to keep this short but meaningful. At the bottom line, there are all kinds of log files and registry keys that show me how, even before the machines(s) are connected to the net, there is an advanced COM+ system installed that then allows an intruder to collect and distribute all my computing behavior to subscribers.
   
   This has defied me, and many a consultant, including high-powered MS remote assistance--sort of like Dante's 9th ring of Hell. What always happens is we start out in agreement that something is very, very fishy, and then when the expert(s) can't fix it definitively, they tell me to stop looking at the log files and registry keys.
   
   No long-reformat reinstall, no DBAN-type write-0s reformat and reinstall, and not even the Vista boot CD from Killdisk will clear this out. Since the original virus attack that brought this to my life over four years ago, there has never been any detection by any of Norton/McAfee/AVG/ and related products.
   
   I have reams of log files, even a copy of the hard drive from whence this all started. My latest obsessional outbreak has come from two things--1) the way Vista and System 7 hide log files from the most of us, and 2)my quest for a new-to-me computer that showed me that signs of this COM+ system were in 6 out of 6 XP machines I looked at.
   
   I am certain that this is not normal, because when I first became obsessed by this situation, I looked at new XP setups all over the place and never saw the log files, and in particular, the COM+ and DCOM setup I see in WMIMGMT.MSC/properties/computers are not normal.
   
   I appreciate any help I can get here.
   
   Thanks....

   Reply

• Older >