| Extremely impressive. ...although it's not clear why this isn't a huge vector to cause all sorts of havoc. The idea of having an executable sandbox that anyone can drop executable code into sounds famously ill-conceived. Every time a site like yahoo mail or myspace has a javascript sanitation problem, this causes major problems.. Sure, the "web at large" is like a big space filled with executable scripts, but at least there is a level of accountability established by the site that is hosting any scripts you're executing. While javascript might execute in a sandbox, it's still wise to use NoScript. I don't know enough about silverlight to know whether or not to trust it, so by default, I am skeptical. I'm even more skeptical of a site that built on the idea of user-contributed apps that run in a silverlight sandbox. I do appreciate the built-in ability to view the source code of the apps, however. The reputation system for apps might also make it possible to crowd-filter out the worst ones. All the same, I saw an app named "infinite" that I imagine amounts to a denial of service. Yes, it was voted "-1" but it's probably a DOS, lurking in the user-submitted apps. Interesting experiment, but I have reservations. |
First the larger question: Is the Silverlight sandbox safe? The Silverlight CoreCLR security model is a simplified version of the full CLR security model [1].
Some callouts:
- C# "unsafe" code blocks, which let you access raw pointers, are not allowed.
- P/Invoke and COM Interop are not allowed.
- There are whole categories of the .NET class library that have been removed, a notable example being local file access. Silverlight is not like Adobe AIR, which gives you all sorts of native APIs.
- Socket communications are restricted by default to the original host from which the Silverlight app was downloaded. Cross-domain access can be granted by supplying either a Flash policy file or a Silverlight-native policy file. [2]
Therefore, to say whether this could be used for DDOS attacks on other hosts, we need to look at the network access policy file. Here it is: http://www.wiki-os.org/clientaccesspolicy.xml . As configured now, Wiki-OS allows incoming HTTP connections from any host, but outgoing connections are only permitted to the original host (and outgoing connections can only use the WebClient-- outgoing raw socket connections are not allowed).
This is interesting. If I'm reading that file correctly, it seems you could write a Wiki-OS network server but not a DDOS vehicle.
[1] "Security In Silverlight 2" http://msdn.microsoft.com/en-us/magazine/cc765416.aspx
[2] "Network Security Access Restrictions in Silverlight" http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx