More Details About CVE-2014-4073 Elevation of Privilege Vulnerability

Today Microsoft shipped MS14-057 to the .NET Framework in order to resolve an Elevation of Privilege vulnerability in the ClickOnce deployment service. While this update fixes this service, developers using Managed Distributed Component Object Model (a .NET wrapped around DCOM) need to take immediate action to ensure their applications are secure.

Managed DCOM is an inherently unsafe way to perform communication between processes of different trust levels. Microsoft recommends moving applications to Windows Communication Foundation (WCF) for inter-process communication instead of using Managed DCOM. Exposing Managed DCOM containers or servers to lower trust callers can result in elevation of privilege vulnerabilities. Please note that DCOM is considered to be secure; only Managed DCOM is considered to be insecure.

More Information:

For more information around why we recommend moving away from Managed DCOM, it is helpful to understand how COM and DCOM work.

COM is a platform-independent, programming language independent, object-oriented system for creating software components that interact. Traditional COM occurs within a single process boundary.

DCOM is similar to normal COM except it allows for objects to be created in different processes or even different computers. This can be useful for distributed computing, or for scenarios where a client application needs to communicate with a server application.

Unfortunately the communications wrapper that the .NET Framework uses to talk to DCOM (also known as Managed DCOM) is unable to maintain this security boundary. If you use managed code to implement either a server or a container, it’s possible for the remote end of the communication channel to take over the managed process. In scenarios where the interaction is taking place inside the same process or between two processes running with the same privilege, this isn’t a problem. However, when the processes communicating with each other run with different levels of privilege, this becomes an issue.

Fortunately there is a solution for developers that rely on this functionality. 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 DCOM to WCF provides a number of examples and code samples to help ease this transition process.

For MS14-057, Microsoft removed the ClickOne deployment service dependency on Managed DCOM. We suggest all developers do the same if they are currently using Managed DCOM to communicate between components running with different privilege.

-Reid Borsuk (Product Security) and Joe Bialek (MSRC)