Before you can tackle the complex security issues around .NET Remoting, it would be helpful to take a moment to dig into the architecture itself. A solid understanding of how remoting works is key to identifying security issues within it.
To understand remoting, it’s helpful to review the technologies you’ve been using up until now, namely the Component Object Model (COM). This will also help you compare the security issues in both COM and .NET. In the COM world, basically two kinds of server objects can be used by clients: in-process and out-of-process. In-process COM objects, like ActiveX dynamic link libraries (DLLs) or ActiveX Controls, are created, used, and destroyed within the same process as the client. The client has direct access to the object since it resides within the same process. Out-of-process objects, like ActiveX EXEs, are created and run within a separate process from the client. If the out-of-process object is running on a machine other than the client’s, then COM uses the Distributed Component Object Model (DCOM) to communicate to it. By the rules of the operating system, a client does not have direct access to an object running in a separate process. Instead, all calls to the object are marshaled via a proxy object.
The .NET architecture is very similar to that of COM with one major difference: AppDomains. Applications in .NET don’t necessarily run in separate dedicated processes; they run in an AppDomain, which provides more of a logical application boundary than a physical one. Depending on the application type, you can have multiple AppDomains running in a single process. Therefore, the .NET equivalent of an in-process object is an object that the client uses that runs within the same AppDomain as the client. And like an in-process COM object, the client has direct access to this type of object. However, if the client uses an object that is running in a different AppDomain, even if that AppDomain is running in the same process, then by the rules of the .NET common language runtime (CLR), the client cannot have direct access to that object. This scenario is functionally equivalent to COM’s out-of-process object. In .NET, the only way to communicate with that object is with remoting. Therefore, remoting is technically defined as the mechanism by which one AppDomain accesses objects in another. This means that remoting is not only used for object communication from one machine to another, but also from one process to another within the same machine, and even within the same process. This is the case because more than one AppDomain can exist in a process.
The type of remoting that requires the most security considerations is machine-to-machine. Interposes and inter-AppDomain remoting is much safer since it involves no network communication.
Tags: .NET, remoting, Remoting in .NET Security, security
Leave a Reply