| although it's not clear why this isn't a huge vector to cause all sorts of havoc. 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 |
Your conclusion is quite interesting, with respect to the possibilities of wiki-os. That's potentially a quite powerful feature.