MS14-072: .NET Remoting Elevation of Privilege Vulnerability

Today Microsoft shipped MS14-072 to the .NET Framework to address an Elevation of Privilege (EOP) vulnerability in the .NET Remoting feature. This update fixes a specific issue in .NET Remoting that permitted specially crafted remote endpoints to take advantage of this vulnerability.

What is .NET Remoting?

.NET Remoting is a layer within the .NET Framework that facilitates communication between application domains (AppDomains). This permits managed objects to communicate across AppDomain, process, or machine boundaries. Objects can be passed by-reference across these boundaries. When methods are called on these objects, control again passes across the boundary to execute within the boundary where the object originated. Refer to .NET Remoting for more details.

Typical use of this is a .NET Remoting service that returns objects by-reference to the client. When the client invokes methods on these objects, code is executed on the server. Similarly, a client can pass an object by-reference to the service, and when that service invokes methods on that object, code executes on the client.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/remoting.png)

Use WCF instead of .NET Remoting

.NET Remoting is a legacy technology that is inherently less secure than WCF. It is unable to preserve isolation of trust levels across the client/server boundary, allowing specially crafted messages to exploit the use of by-reference objects to achieve an elevation of privilege. It also uses a legacy serialization technology that makes the server vulnerable to denial-of-service attacks. Because of this we recommend developers of distributed applications based on .NET Remoting to consider porting their code to Windows Communication Foundation (WCF) which is more secure.

The boundary transparency in .NET Remoting makes it possible for a remote untrusted endpoint to take control of a .NET Remoting service. Because the service typically executes with full privileges, this permits a remote endpoint with lower privileges to elevate themselves using functionality exposed by .NET Remoting services. Within a completely trusted environment, this is normally not a problem. But if the .NET Remoting service is exposed to untrusted remote endpoints, this becomes an issue as it crosses the security boundary.

Read about how .NET Remoting works to know more information around why we recommend moving away from it.

The Windows Communication Foundation (WCF) unified programming model is designed to be robust when communicating with untrustworthy endpoints. In many cases this may be a small exercise to move to the newer, more supported technology. The MSDN article entitled How to: Migrate Managed-Code .NET Remoting to WCF provides a number of examples and code samples to help ease this transition process.

Securing .NET Remoting services

Moving to newer technology takes time, meanwhile here are some steps to make .NET Remoting service more secure:

• Set ensureSecurity flag set to true while registering channel:

This enables encryption and digital signatures if the remoting system determines that the channel implements ISecurableChannel.

• Always authenticate clients and encrypt the communication streams:

There is no authentication or encryption by default, developers have to do this explicitly.

• Keep the permission level of the .NET Remoting service at minimum to what is required so as to avoid having a big security boundary.

- Swamy Gangadhara (MSRC) & Ron Cain (.NET)