Binary Design and Least Privileged Users (LUA)

Programs run in user accounts in order to be authenticated, authorized and accounted for their actions. Assume that a program is running in a certain user context, every action in that program will have same user access rights, and so will the worms and remotely injected malicious code. Usually, not whole application necessarily requires all access privileges that some special parts may require. Modularizing programs into parts of their required user privileges and giving those parts “just enough” access rights will protect computers in case of faulty behavior and/or malicious activity. This practice is called running programs in “Least Privileged User” account.

One important thing to notice is that the use of “least privilege” does not necessarily mean really using least privileged user account in that system. It means that the user account that the program is running in has only minimum level of privileges that allows its execution, all other access rights are voluntarily given away.

There are several methods to enable LUA [15]. Although COM is widely used on MS Windows based applications, its use as a mechanism to enable LUA was not documented before. Extending capabilities of such a widely used technology is main motivation of this section.

5.6.2. Previous Work

[17] gives tremendous amount of information about DLLs in MS Windows and their OS level implementation. [34] gives information about creating DLLs and using them in applications. [35] and [36] gives information about how to enable COM authentication and authorization, which is required knowledge to implement ideas of this thesis. Unfortunately, COM is an old technology and its existence is well before security awareness. At the time that COM emerges, there have been some articles about its efficient usage. Later on, interest in COM (and other similar technologies like CORBA) is decreased with the introduction of later and advanced technologies. This hampered research on COM technology. Therefore, even after security pushes, researches did not go back and look at COM. Even security articles about LUA presented other approaches that had different advantages. However, author of this thesis decided to work on this technology because of the reasons mentioned on motivation section.

5.6.3. Background Information: DLLs

Dynamic Link Libraries have many advantages over static ones. First, as its name implies, it is possible to select desired library at the runtime. For example, different strategies with same interfaces can be distributed to different DLL’s. At the runtime, executable can read an initialization file (or query registry in Microsoft Windows) and load desired library. Another advantage is that some DLL’s do not get loaded until there is an explicit request to functionality in it. Those DLL’s are called delay loaded DLL’s and most of the DLL’s can be specified as delay loadable during compile time of the library. Yet another good side with DLL’s is that they are shared among different processes on the same machine. Unlike statically linked libraries, same instance of DLL is shared. For example, C runtime library is so widely used; statically linked programs will carry and load their copy of the library, thus wasting space and reducing likelihood of successful cache hits. Shared CRT could save space and since only one copy would reside in the memory, there is much less chance that it is swapped out.

In the security perspective, DLL’s present some interesting traits: since DLL’s help projects to be divided into smaller independent binary modules, it is possible to update modules individually. Assume that new security vulnerability is found in the

300 MB application. Users would have a very bad time to patch it from the Internet if the application is monolithic; users would have to download the whole 300 MB of data. This is very discouraging; users will try to combine downloads among different security updates, while in the meantime their systems will be left vulnerable. With DLL’s in the scheme, it is possible to update DLL’s that needs fix, which will be only a few hundred KB’s usually.

However, on the downside, there are points to be aware while using DLL’s. Since they are separate from executable binary, executable has no control on their authenticity. A malicious DLL presenting same interface can be named exactly as the old one and be replaced with it. Executable then will load this DLL, without knowing it is malicious. Operating system will run a digitally signed executable without user confirmation, however digital signatures are limited to executables. Executable will load malicious DLL and most probably will do things that are not intended at all. This problem can be resolved with DLL checksums and hashes.

5.6.4. Background Information: Privileges and Access Rights

Access rights are the rights that allow or deny selected set of users from performing certain operations. An operating system object can have an access control list, which defines who is allowed to do what and who is denied from doing what. This is similar in firewall or router access lists. Access rights are applied to single objects. Although objects (most notably file system entities) can inherit ACL’s from their parents, this should not confuse the readers, objects still have their private ACL, only thing is setting ACL’s on multiple files is done easier that way. For instance, file deletion, mutual exclusion object releasing, process terminations are all access right checked operations.

Privileges are global access rights and they do not apply to objects. For example, taking ownership of objects, kernel debugging, running in system context, allocating physical pages are special privileges that are granted on user bases. Some users have only a few of those privileges, more powerful ones (notably administrators or roots) have most or all of them. Since privileges have broader applicability, they are generally more powerful. For instance, a user account having the privilege of taking ownership of objects can read or write any object in that system, even if there is no specific ACL that grants performed operation.

5.6.5. COM Encapsulation

Component Object Model can be seen as advanced version of DLL’s. They present same advantages and add other ones at their own. “DLL Hell” is not anymore an issue with COM; it has its own versioning scheme.

The interesting thing with COM from security perspective is that they can be loaded in process or out-of-process. If a COM binary is in process, it is pretty much the same as DLL’s. Function calls will be handled in the same address space and privilege level as the host process. If a (for example “parser”) function is compromised, then whole executable is compromised. Attacker will have exact security rights as the process, and every action the attacker takes will be accounted to the principle that created the process.

Figure 5.12: Address space with regular DLL usage.

Out-of-process servers, on the other hand, will have their own memory space and security context along with privileges. Since there is no direct address space mapping among executable and COM module, RPC mechanism is used to get them communicated properly. Every call will be marshaled and send via some transport protocol to the server. Replies from the server will be returned similarly. Please see below: App.Exe CRT.DLL Crypto.DLL Parsers.DLL HelperForParser.DLL Network Listener.DLL Sockets.DLL CRT.DLL CRT.DLL App.Exe CRT.DLL Crypto.DLL Parsers.DLL HelperForParser.DLL Network Listener.DLL Sockets.DLL

Figure 5.13: Address space with COM usage.

On the picture, “Crypto.DLL” represent an in-process COM server, thus it is loaded into the same address space as executable itself. “Parser.Exe” is a out-process COM module with some DLL dependencies of its own, thus it loaded into different address space with its DLL’s. Similarly, “NetworkListener.Exe” is another out-process COM module and it is loaded into another address space with its dependencies. Address space of executable does not have direct access to other spaces; it must use some inter process communication (IPC) mechanism. COM uses RPC as IPC. Each call to these different spaces is first marshaled, and then transferred with some transport protocol (LPC, TCP, UDP, etc.).

Beauty of this scheme is that different address spaces can have different security settings and privileges. If, for instance, “NetworkListener.Exe” process is compromised, attacker will be able to use only its access rights. In a security conscious system, this process would have almost no rights, which makes a successful attack almost useless.

Since RPC can use different transport protocols that are transparent to COM, different process spaces can reside in different physical machines. This is called Distributed COM, DCOM. This tremendous amount of flexibility allows architectures as below: App.Exe CRT.DLL * Crypto.DLL * Parsers.Exe HelperForParser.DLL * Network Listener.Exe Sockets.DLL CRT.DLL CRT.DLL App.Exe CRT.DLL Crypto.DLL * Parsers.Exe CRT.DLL HelperForParser.DLL * Network Listener.Exe Sockets.DLL

Files and Dependencies Address Spaces at Runtime

RP C C ha nn el RP C C ha nn el * COM Modules

Figure 5.14: Sample architecture with out-of-process COM usage

“Figure 5.14: Sample architecture with out-of-process COM usage” presents a sample architecture, where computers of different roles reside in different and access controlled network segments.

5.6.6. COM+

COM+ COM with some advanced transaction services. These services make role based security and transaction management very easy and robust. DCOM developers should gain information about COM+, use integrated features rather than developing their custom code, and spend time on testing, improving, and hardening.