Per my original statement, I replied because I wanted our developers to understand that we are aware of the need, and we are working on a solution. I'm not going to try and explain all of the potential exploits that are possible, only say that providing
a fundamentally secure solution takes time. We take this stuff very, very seriously - we have to.
andulvar
Several of us here would like to hear what your rationale is for these restrictions. I certainly can't think of any good reasons for them.
We employ experts in network security for precisely this reason, many of them with years of experience. They have pointed out that this is a feature that needs to be done correctly, and have been able to point out all sorts of pitfalls that happen when you
don't do things like securely exchange a policy file. Flash shifted from a more open model (similar to what's been suggested on this thread) to a much more locked down model last year - details of which are outlined here:
I can guarantee you that Adobe did not implement this kind of policy change without good reason. It's certainly not in our best interests to withhold important features that people are asking for, but we cannot ship something that is fundamentally insecure.
I read that article with great interest. It goes a long way to explaining your concerns. I'll calm down now.
I noticed one rule that Silverlight does not support, but which would be extremely helpful for us: In Flash, a socket can be opened on any port that serves its own policy file. This would go an extremely long way in solving some of the problems that I
am facing. It would eliminate the need for a low-numbered port to serve the policy file, and would mean that only one port, of the user's choice, would need to be opened in the firewall. There would still be problems with customers who refuse to open any
ports (we would normally use port 80 to get through the firewall in that case), but it would help.
Also, I see that you decided to use port 943 for the socket policy server port, rather than the 843 that Adobe uses. What is the rationale for using a different socket, rather than an existing de-facto (soon to be IANA) standard, to do the same thing?
Presumably you want to use a different file format, but why? That's just making things harder on your users.
So, as I read the Adobe security rules, I see:
- Flash allows socket connections to any port, including sub-1024 ports.
- Flash allows a server to serve the policy file on the just-connected socket if there is no policy server at port 843.
- Flash is applying for an IANA-assigned port number for policy servers, which will greatly ease the problem of convincing sysadmins to open the port for outbound traffic.
It would be a lot less painful for your users if Silverlight also followed this thinking. They have clearly found a better approach to usability while maintaining security than Silverlight currently offers. Do you know something that Adobe doesn't that
makes their security measures unsafe?
I do not understand you quote the Flash Policies as an analoque to this discussion. We follow that policy, and everything works like a charm, which to my understading wouldn´t be possible in Silverlight.
Policy files, and port range restrictions are ridiculous to claim as security measures. These restrictions do not exist for a standard installed application, and because of this servers need to protect themselves. Once a server publishes a port on an IP,
they have 'opted in' to all communication on that port, regardless of the client. They can implement whatever other security (handshakes, client IP restrictions, etc) they want, but it's assumed to be the server's responsibility to secure themselves.
If I can already send all the data I want from silverlight to my own server without a prompt (and from there do whatever I would like with it), the only thing circumvented would be IP restrictions, but I think a confirmation/security dialog would be more
than enough to mitigate that.
Kellen, reading that paper from Adobe is really quite helpful. It points out a malicious DNS server attack that I would frankly never have thought of. Remember that the security of a system is only equal to its least secure component, so if the Silverlight
client gets everything "right" but for one attack vector, that's the attack vector that will be used on it.
I can see a rationale for restricting ports to above 1024: it stops a Silverlight client from sneaking out through a firewall via a port opened for other purposes. Personally I would like that to be allowed, possibly with a confirmation dialog, but I understand
that it has to be handled carefully. I cannot really see a rationale for restricting the port range above 1024, but I'm feeling somewhat humbled after the Adobe paper, so I'm willing to concede that I don't know everything.
The presence of a permission file on the server does not protect the server from arbitrary clients, but it does help protect the server from malicious Silverlight applications. Normally to mount a distributed attack on a server you need a botnet. Imagine
if you could design a Silverlight application that can do it for you instead? Now all you need is a popular web site with an innocuous-looking animation in one corner, and the whole world could participate unwittingly in the attack
without their machine ever being compromised. Don't think you could get enough participants? Think sex.com.
Silverlight and Flash applications occupy a special niche in the web. Virtually everybody will allow them to load and run, and will probably give them whatever permissions they ask for. Anti-virus programs may have a tough time working out whether they
pose a threat. They're unlike HTML, JavaScript or executables in their level of danger. So the apparent purpose of the permission files is solely to ensure that Silverlight apps cannot be used for attacks against the server, not as a general purpose way
for the server to protect itself from all comers. Silverlight implements these restrictions to protect servers from Silverlight.
If Silverlight could open sockets to ports on the LAN, or to well-known ports anywhere, without some kind of explicit permission, then a Silverlight app could load from a malicious external page, make a socket connection to that external server, and then
begin fishing around on the local LAN for a web, FTP, whatever server that is firewalled from the Internet, but available on the local LAN. When it found something unprotected, it could connect to it and begin transferring data from inside the LAN to the
malicious Internet server. Effectively a malicious Silverlight app can act as a way to completely breach the corporate firewall and steal information from anywhere on the LAN. The permission file requirement makes this scenario impossible, unless the server
on the LAN actually offers an explicit permission file to the Silverlight app. Since this is a positive action that the system administrator must take, the Silverlight app will be totally blocked by default.
In summary, I'm coming to believe that the goals of the socket restrictions are valid. I don't necessarily agree with the implementation. There are lots of ways to skin a cat, and I'd like to see a solution that is as unrestrictive as possible, but still
handles completely all of the security threats. I'm not advocating for lax security, just maximum flexibility.
I'm reading the paper now, but one thing I would certainly advocate is the "user initiated action". Silverlight right now requires a user fired event to even prompt a user if they want to allow silverlight to increase the size of storage allocated to a
page.
The DNS exploit described requires that a policy file concept exists in order to be exploited. If silverlight had no concept of a policy file, there would be no policy file to attempt to inject. Requiring a user interact, and then accept a confirmation would
seem like a much more secure model than we have now.
Requiring user interaction, with the possibility to restrict silverlight as a whole via group policy (so not the SL applications choice), and even a silverlight version of windows firewall (so that you have to give individual SL applications access to individual
ports) would put us at the same level as if someone just linked an .exe that had socket access. Unless I'm missing something.
Edit to add: I'm not crazed about this or anything, I love silverlight and use it whenever I can, it's just frustrating to write a WPF app that'd be perfect in silverlight if only I could connect to another domain's open port (and it works fine connecting
to my server and then relaying, I just can't go to production like that.
Well something like a policy file *is* needed - some way for the owner of a server to control what servers can access it's data.
granted the policy file does not cover all aspects of that issue but it does provide a basic filter on who may connect to that server.
by having the client tell the policy server the domain it came from is a start at trying to id the source of the app that is trying to connect.
this gets into the area that the msft folks may be looking at: how to build a safe way to auth and not let clients trick the server of the data into accepting forged identity info like the domain name....
If a server is opening up a port, with or without a policy file, clients can connect to it, all that this concept of a policy file does is not allow
silverlight clients to connect. I could still write a WPF client that connects regardless of policy (and distribute this as a link on a web page... which would require a 'user initiated action' followed by a confirmation to run... like I'm
advocating).
tomtaylormsft
Member
579 Points
165 Posts
Microsoft
Re: Lacking arbitrary socket support
Mar 22, 2009 05:49 AM | LINK
Per my original statement, I replied because I wanted our developers to understand that we are aware of the need, and we are working on a solution. I'm not going to try and explain all of the potential exploits that are possible, only say that providing a fundamentally secure solution takes time. We take this stuff very, very seriously - we have to.
We employ experts in network security for precisely this reason, many of them with years of experience. They have pointed out that this is a feature that needs to be done correctly, and have been able to point out all sorts of pitfalls that happen when you don't do things like securely exchange a policy file. Flash shifted from a more open model (similar to what's been suggested on this thread) to a much more locked down model last year - details of which are outlined here:
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
I can guarantee you that Adobe did not implement this kind of policy change without good reason. It's certainly not in our best interests to withhold important features that people are asking for, but we cannot ship something that is fundamentally insecure.
- Tom
Tom Taylor | Microsoft Silverlight
Magikos
Member
529 Points
220 Posts
Re: Re: Lacking arbitrary socket support
Mar 22, 2009 04:45 PM | LINK
Thanks Tom.
andulvar
Member
181 Points
129 Posts
Re: Re: Lacking arbitrary socket support
Mar 22, 2009 05:06 PM | LINK
I read that article with great interest. It goes a long way to explaining your concerns. I'll calm down now.
I noticed one rule that Silverlight does not support, but which would be extremely helpful for us: In Flash, a socket can be opened on any port that serves its own policy file. This would go an extremely long way in solving some of the problems that I am facing. It would eliminate the need for a low-numbered port to serve the policy file, and would mean that only one port, of the user's choice, would need to be opened in the firewall. There would still be problems with customers who refuse to open any ports (we would normally use port 80 to get through the firewall in that case), but it would help.
Also, I see that you decided to use port 943 for the socket policy server port, rather than the 843 that Adobe uses. What is the rationale for using a different socket, rather than an existing de-facto (soon to be IANA) standard, to do the same thing? Presumably you want to use a different file format, but why? That's just making things harder on your users.
So, as I read the Adobe security rules, I see:
- Flash allows socket connections to any port, including sub-1024 ports.
- Flash allows a server to serve the policy file on the just-connected socket if there is no policy server at port 843.
- Flash is applying for an IANA-assigned port number for policy servers, which will greatly ease the problem of convincing sysadmins to open the port for outbound traffic.
It would be a lot less painful for your users if Silverlight also followed this thinking. They have clearly found a better approach to usability while maintaining security than Silverlight currently offers. Do you know something that Adobe doesn't that makes their security measures unsafe?
lars67
Member
4 Points
8 Posts
Re: Re: Re: Lacking arbitrary socket support
Mar 22, 2009 05:27 PM | LINK
Here we have a real-life problem due to this S***** policy
http://silverlight.net/forums/t/82650.aspx
lars67
Member
4 Points
8 Posts
Re: Re: Re: Re: Lacking arbitrary socket support
Mar 22, 2009 05:39 PM | LINK
Hello Tom Taylor
I do not understand you quote the Flash Policies as an analoque to this discussion. We follow that policy, and everything works like a charm, which to my understading wouldn´t be possible in Silverlight.
This is a complete showstopper for us.
Our application http://www.softcapital.com/radarlite works, a port to Silverlight will not. Why the strict rules against port 80?
GuinnessKMF
Member
222 Points
58 Posts
Re: Re: Re: Re: Re: Lacking arbitrary socket support
Mar 24, 2009 04:53 PM | LINK
Policy files, and port range restrictions are ridiculous to claim as security measures. These restrictions do not exist for a standard installed application, and because of this servers need to protect themselves. Once a server publishes a port on an IP, they have 'opted in' to all communication on that port, regardless of the client. They can implement whatever other security (handshakes, client IP restrictions, etc) they want, but it's assumed to be the server's responsibility to secure themselves.
If I can already send all the data I want from silverlight to my own server without a prompt (and from there do whatever I would like with it), the only thing circumvented would be IP restrictions, but I think a confirmation/security dialog would be more than enough to mitigate that.
andulvar
Member
181 Points
129 Posts
Re: Lacking arbitrary socket support
Mar 24, 2009 06:42 PM | LINK
Kellen, reading that paper from Adobe is really quite helpful. It points out a malicious DNS server attack that I would frankly never have thought of. Remember that the security of a system is only equal to its least secure component, so if the Silverlight client gets everything "right" but for one attack vector, that's the attack vector that will be used on it.
I can see a rationale for restricting ports to above 1024: it stops a Silverlight client from sneaking out through a firewall via a port opened for other purposes. Personally I would like that to be allowed, possibly with a confirmation dialog, but I understand that it has to be handled carefully. I cannot really see a rationale for restricting the port range above 1024, but I'm feeling somewhat humbled after the Adobe paper, so I'm willing to concede that I don't know everything.
The presence of a permission file on the server does not protect the server from arbitrary clients, but it does help protect the server from malicious Silverlight applications. Normally to mount a distributed attack on a server you need a botnet. Imagine if you could design a Silverlight application that can do it for you instead? Now all you need is a popular web site with an innocuous-looking animation in one corner, and the whole world could participate unwittingly in the attack without their machine ever being compromised. Don't think you could get enough participants? Think sex.com.
Silverlight and Flash applications occupy a special niche in the web. Virtually everybody will allow them to load and run, and will probably give them whatever permissions they ask for. Anti-virus programs may have a tough time working out whether they pose a threat. They're unlike HTML, JavaScript or executables in their level of danger. So the apparent purpose of the permission files is solely to ensure that Silverlight apps cannot be used for attacks against the server, not as a general purpose way for the server to protect itself from all comers. Silverlight implements these restrictions to protect servers from Silverlight.
If Silverlight could open sockets to ports on the LAN, or to well-known ports anywhere, without some kind of explicit permission, then a Silverlight app could load from a malicious external page, make a socket connection to that external server, and then begin fishing around on the local LAN for a web, FTP, whatever server that is firewalled from the Internet, but available on the local LAN. When it found something unprotected, it could connect to it and begin transferring data from inside the LAN to the malicious Internet server. Effectively a malicious Silverlight app can act as a way to completely breach the corporate firewall and steal information from anywhere on the LAN. The permission file requirement makes this scenario impossible, unless the server on the LAN actually offers an explicit permission file to the Silverlight app. Since this is a positive action that the system administrator must take, the Silverlight app will be totally blocked by default.
In summary, I'm coming to believe that the goals of the socket restrictions are valid. I don't necessarily agree with the implementation. There are lots of ways to skin a cat, and I'd like to see a solution that is as unrestrictive as possible, but still handles completely all of the security threats. I'm not advocating for lax security, just maximum flexibility.
GuinnessKMF
Member
222 Points
58 Posts
Re: Re: Lacking arbitrary socket support
Mar 24, 2009 08:55 PM | LINK
I'm reading the paper now, but one thing I would certainly advocate is the "user initiated action". Silverlight right now requires a user fired event to even prompt a user if they want to allow silverlight to increase the size of storage allocated to a page.
The DNS exploit described requires that a policy file concept exists in order to be exploited. If silverlight had no concept of a policy file, there would be no policy file to attempt to inject. Requiring a user interact, and then accept a confirmation would seem like a much more secure model than we have now.
Requiring user interaction, with the possibility to restrict silverlight as a whole via group policy (so not the SL applications choice), and even a silverlight version of windows firewall (so that you have to give individual SL applications access to individual ports) would put us at the same level as if someone just linked an .exe that had socket access. Unless I'm missing something.
Edit to add: I'm not crazed about this or anything, I love silverlight and use it whenever I can, it's just frustrating to write a WPF app that'd be perfect in silverlight if only I could connect to another domain's open port (and it works fine connecting to my server and then relaying, I just can't go to production like that.
figuerres
Participant
1304 Points
351 Posts
Re: Re: Re: Lacking arbitrary socket support
Mar 24, 2009 10:18 PM | LINK
Well something like a policy file *is* needed - some way for the owner of a server to control what servers can access it's data.
granted the policy file does not cover all aspects of that issue but it does provide a basic filter on who may connect to that server.
by having the client tell the policy server the domain it came from is a start at trying to id the source of the app that is trying to connect.
this gets into the area that the msft folks may be looking at: how to build a safe way to auth and not let clients trick the server of the data into accepting forged identity info like the domain name....
GuinnessKMF
Member
222 Points
58 Posts
Re: Re: Re: Re: Lacking arbitrary socket support
Mar 24, 2009 10:31 PM | LINK
If a server is opening up a port, with or without a policy file, clients can connect to it, all that this concept of a policy file does is not allow silverlight clients to connect. I could still write a WPF client that connects regardless of policy (and distribute this as a link on a web page... which would require a 'user initiated action' followed by a confirmation to run... like I'm advocating).