APIs with Name-Squatting Issues

CreateDirectory, CreateEvent, CreateFile, CreateFileMapping, CreateHardLink, Create Job Object, CreateMailslot, CreateMutex, CreateNamedPipe, CreateSemaphore, CreateWaitableTimer, MoveFile, and classes that wrap these APIs

Any API call that can create something with a name is prone to name-squatting issues. There are two parts to the problem. The first is that the attacker would like to guess what file or other object is being created and then create it before you get there. For example, if when I edit a file the editor creates a file with a predictable name in c:\temp, an attacker could precreate the file with permissions that allow her to read it and then manipulate my file. Another attack is to link to a file I don't have write access to and then get an administrator to delete it for me or, worse yet, to change the permissions. The solution to most of these types of attacks is to use per-user temporary space, located in the user's Documents And Settings folder, assuming that we're dealing with Microsoft Windows 2000 or later. If you have to create temporary files or directories in a public area, the best approach is to generate a truly random name for your object. The second part of the solution, when creating files, is to use the CREATE_NEW flag, which will cause the function to fail if the file already exists.

Never assume that a file or other object does not exist if you checked to determine whether it was present. There is a window of opportunity between checking for existence and creation in which an attacker can exploit you. The timing might be tight and you might think that the chances of pulling off such an attack are miniscule, but think again! Numerous potent attacks have been made against UNIX systems that were vulnerable to race conditions, and a few we've seen have affected Windows as well. Windows isn't any less vulnerable it just typically doesn't have multiple local users at once, unless you're running Terminal Services.

Named pipes have another set of issues, which is that the owner of a named pipe can often impersonate the client, depending on how the client opened the pipe. If the client is a high-level process, this can lead to escalation of privilege. One way to defend yourself against this attack is to open your pipe with the FILE_FLAG_FIRST_PIPE_INSTANCE flag set. Note that this works only on Windows 2000 SP1 and later. This is covered in detail in Chapter 23, General Good Practices.

Here's one approach that overcomes the escalation of privilege attack: when your server starts, it generates a random name, creates the pipe with that name, and stores the name in a registry key that is writable only by administrators. Clients then check the registry key to determine the pipe to open. If the server exits, it clears the value in the registry. Although this is a good method, attacks still exist if your server can be caused to exit without clearing the stored pipe name.

If your server exposes either RPC interfaces or named pipes across the network, the clients are going to depend on a particular interface ID or pipe name existing on the server. The best bet in these instances is to ensure that your service starts as early as possible in the boot order.