Principle of Least Privilege

The principle of least privilege states that you should give a user the ability to do what he needs to do and nothing more. Properly defining the boundary between your application binaries and user data will also make your application easier to secure, not to mention help you attain Windows 2000 (and later) compliance. So let's think this through: who really needs to be able to overwrite your binaries? Typically, that would be administrators, and, if your application allows ordinary users to install a personal copy, creator-owner should have full control access. And who needs to be able to write data files to your installation directory? Hopefully, no one any files written by an ordinary user ought to be kept in that user's profile. If you do allow users to write their own files to a common directory, you need to be careful with the access rights.

Now consider configuration settings I hope you're storing per-user configuration settings under HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE. Apply the same logic to your configuration information that you would to the file system. Is this application sensitive enough that nonadministrators shouldn't be changing the settings? Would any of the configuration settings possibly lead to escalation of privilege?

Let's look at some real-world examples. The Systems Management Server (SMS) Remote Agent service runs under the local system context, but the folder that it is installed into allows everyone full control access by default. For full details (and a fix), see http://www.microsoft.com/technet/security/bulletin/fq00-012.asp. I'm aware of services shipped by other vendors that make the same mistake. In general, an application should never grant everyone write access, and if the application is meant to be primarily run by administrators or the local system account, only administrators should be able to change the executable.

The permissions on the AeDebug key under Windows NT 4.0 show another problem. AeDebug specifies the application that should be run if another application crashes. Although the binary that should have been run was safe on the file system, the configuration settings that pointed to it weren't properly secured. (The details can be found at http://www.microsoft.com/TechNet/security/bulletin/fq00-008.asp.) What good does that do, you might ask. So what if I can crash one of my own applications it will just run the debugger under my user context. What if there is an application that is running under the local system account that has a DoS vulnerability present? (This is a good example of why even application crashes can be very dangerous.) Now we can change the debugger, crash the application, and have local system executing the code of our choice!

A milder form of the same problem happened with the Simple Network Management Protocol (SNMP) parameters, detailed in http://www.microsoft.com/TechNet/security/bulletin/fq00-096.asp. SNMP short for Security Not My Problem, according to a friend of mine is an insecure protocol that is widely used for network management chores. SNMP bases access controls on a shared secret known as a community string. It isn't a very good secret because it will be found on dozens of devices, and to make matters much worse, it's transmitted almost completely in the clear (obfuscated with a programmer-unfriendly encoding scheme). Anyone with access to a network sniffer can capture a few of these packets, decode the information, and capture the community string. The problem with the permissions on the Parameters subkey for the SNMP service is that everyone has read permission by default (locally you can't get to it from the network). If a community string that has write access is present, an ordinary user can read it, send the system SNMP SET requests, and do things she should not. Even more severe examples of the same problem exist. Certain applications have been known to store passwords sometimes only weakly encrypted or in the clear in world-readable portions of the registry and even embedded in files. The important thing to remember is that some information shouldn't be accessible to just anyone who logs on to the system. Think about whether your application has information like this, and make sure you protect it properly.

Another problem I sometimes see is information that has differing levels of security needs stored in the registry under the same key. Unlike the file system, you can't set access controls on individual values under the same registry key. Consider a situation in which one value could have serious security implications (e.g., the user account the service uses) and there is another value that the user account running the application must be able to update. Now you have a problem. To properly secure the key, the key must be writable by only administrators. This implies your application must run as an administrator-level account. Now when your application gets compromised, the whole system gets compromised as well. If you try to run your application as an ordinary user, the attacker only needs to use the app to modify the security-sensitive value. The bottom line is to store only information with the same security needs in the same registry key. The same issue applies to a configuration file.

I was recently in a meeting with a group that wanted my advice on how to best secure portions of their application. I asked how they secured their files, and they replied, We always write into the Program Files directory it has good access controls by default. It's true that Program Files has a reasonable set of permissions, so I asked what happened if the user chose to install somewhere else, say, off the root of a freshly formatted NTFS partition. They started looking worried, and rightfully so their application would have ended up granting everyone full control. To avoid this situation, take control of your own access control lists.