Why does Silverlight have a restricted port range for Sockets?

Silverlight restricts the ports of outgoing TCP socket connections to the range 4502 – 4534. Connecting to a different port requires the use of a server-side proxy or port redirector.

One of the most common questions we hear from customers about this is, “Why do you restrict the port range in Silverlight? It doesn’t add any extra security.”

Actually, it does. The short explanation is, it gives network administrators control over their infrastructure by providing a convenient way to distinguish and route Silverlight traffic. For the long answer, read on.

Desktop trust model

When you run an application on your desktop you typically:

• Have intentionally downloaded and/or installed the application
• Have intentionally executed the application

In the case of a managed corporate environment you:

• Have been granted permission by an IT administrator to install and/or execute applications on your PC

In short, by being able to install and explicitly execute an application, you are asserting your trust of that application to not go rummaging around your file system or corporate network, for instance.

Web trust model

The web trust model is different. A web browser is a trusted desktop application, so per above, there are expectations it will not do anything malicious. Since web content can come from anywhere, there are no security guarantees about the intentions of the content provider.

Moreover, the explicitness of application install and execution is not present by design. That is, just by navigating to a website, a number of Silverlight applications could be started – an advertisement playing in the corner of the page, a hidden application with no UI, etc.

None of these Silverlight applications should be able to break out of the “sandbox” trust model without your knowledge, and nothing short of application signing, a domain trust model, prompting, etc. could establish that trust.

We’ve worked hard to keep the experience as unobtrusive as possible by generally avoiding prompting. But even when necessary, such trust models are fragile in nature because there is such a tendency to just click OK when you’re on a trusted site, even if the content came from elsewhere.

User vs. IT admin security decision

The other consideration is whether the decision to trust a website or Silverlight application rests with the web browser user or with the IT administrator. An insecure client on the network can be an entry point to other normally secured systems.

Here is one well-known FTP attack for why a trust decision like this is necessary and why it needs to rest with the IT admin.

The FTP protocol has a PORT command which is typically used to establish connections using “active” FTP. It can also be used to initiate server-to-server transfers.

In a malicious case, the command can be exploited to perform port scanning, or in the case of some active packet filtering devices, to actually open ports in the firewall.

With a desktop FTP client application that the user or IT admin has installed, the behavior of that client is trusted to be benign and these commands are issued at the request of the user. The active packet filter is doing what it was configured to do by opening the necessary ports to allow the connection.

Now imagine if Silverlight were allowed to send those same commands. You visit a website, a hidden application sets up a TCP connection back to its server of origin, and then it sends the PORT command which promptly opens a hole in your firewall. The website then uses this open port to establish a connection back to a victim machine on the internal network. The user never intended this action and therefore the trust model is broken. Moreover, the entire network has been placed at risk since the connection could be to a different computer than the user’s who indicated trust of the application.

Now, such attacks can typically be mitigated through additional configuration and patching, but this class of attack tends to re-surface with various protocols because of the liberties active filters take.

Similar exploits exist for HTTP. You’ll notice that Silverlight, Flash, XmlHttpRequest, etc. block a number of request headers. Now imagine if we allowed TCP connections over port 80 and a malicious application could craft their own HTTP request, effectively bypassing our HTTP implementation which has these checks.

For a detailed look at one such threat, please see this article about CERT’s VU#435052. Security researcher Dan Kaminsky has published a presentation and paper on the subject.

In a corporate environment, IT administrators need to be able to secure their networks against such attacks, so there must be a way for them to retain control of these security decisions and to also be able to distinguish Silverlight traffic from trusted application traffic that might be using similar protocols.

Port ranges and transparent proxy abuse

So how do port ranges help? Well, it’s unlikely your active packet filter scanning FTP port 21 is going to notice if someone attempts to send a maliciously crafted command over port 4502. Moreover, with a clearly identified port range of Silverlight-only traffic, it’s easy to configure such filtering devices to handle that traffic differently and with an appropriate level of trust.

Other solutions

There are other solutions to this problem. I briefly mentioned some approaches the application model could take along with some of the drawbacks. Another alternative would be to require obfuscation or encryption of all traffic to keep active packet filters from inspecting packets. This has the drawback of not necessarily being compatible with all protocols, with defeating the optimizations active packet filters can provide, and with making it more difficult to distinguish between desktop application vs. Silverlight initiated network traffic.

Conclusion

For the time being, we’ve settled on the port range restrictions as the best compromise to maintain security and protect our customers. We understand this makes interoperability and connectivity challenging for some deployments, but we are planning to address that feedback with future work in this area.

I hope this helps to clear up some of the questions out there about this, and if you have more, please let us know. Thanks!

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS