Changing access control on folders vs. files

This post is the fourth installment in the "Fixing LUA Bugs" series. Before reading this, you should read:

A fairly common LUA bug scenario is the application that creates and modifies files in the same folder as its executables. For example: "C:\Program Files\VendorX\AppX.exe" creating a file called "C:\Program Files\VendorX\InfoX.dat" and writing to it. What are the risks for loosening permissions on the VendorX folder rather than just the InfoX.dat file? What about loosening permissions on the folder and then re-establishing tighter permissions on the executables?

Consider the scenario of arbitrary malware having been executed by the interactively logged-on "User A" – perhaps because of a browser exploit or an IM- or email-based worm. The malware runs in the context of the logged-on user. If User A is a non-admin (and assuming no exploitable elevation-of-privilege vulnerabilities), the malware could control everything that User A sees and does, but should have no effect on other users of the computer or on the integrity of the operating system itself. For example, User A cannot install a rootkit or other malware that runs when User B logs on; cannot change User B's Start menu items or the All Users' Start menu items; cannot change system executables such as cmd.exe or apps under Program Files. The threat to consider here, therefore, is whether changing access controls for the shared app can enable the malware to compromise other users or the operating system.

Assuming User A already compromised and permissions on the AppX folder having been loosened, the risks increase as you move through the following scenarios:

AppX or its data on ComputerA is used by:

Resulting threat

… User A (a single non-admin user)

Negligible additional threat – the user's profile has already been compromised. AppX folder/files are one more thing that needs to be cleaned in order to prevent re-infection.

… multiple non-admin users

Attacker can use AppX/data as a vector to compromise other non-admin users, by causing arbitrary code to execute when AppX is used. Each user who uses AppX is affected; operating system integrity is not compromised.

… a LocalSystem service or by a member of the Administrators group (or equivalent, including Power Users)

Attacker can use AppX/data as a vector to gain admin/system privileges, by causing arbitrary code to execute when AppX is used. Entire system can be completely compromised.

It is easier to run arbitrary code by attacking executable code files than by attacking data files. "Executable code files" includes binary images such as .exe, .dll, and .ocx files, but also text files such as .cmd, .vbs, .js, .htm/.html/.mht, and even .xml (depending on how it is used). It is straightforward to directly modify executable files to include or invoke arbitrary commands of the attacker's choice.

What if access is loosened on the application folder to allow creation of files or subfolders, but ACLs are applied directly to the executable files to prevent their modification? That can prevent direct modification, which may frustrate and derail some attackers, but:

  • If the application folder allows creation of new folders or files, an attacker can use DLL redirection to cause an application to load and execute substituted DLLs in place of shared DLLs without touching any existing files.
  • Files can be affected by making changes to their directory entries in the containing folder. For example, loosened permissions on the application folder can allow the user to rename or delete a file in the folder – note that these are actually changes to the directory, not to the file – and then replace it with a Trojan.

Generally speaking, executing arbitrary code by attacking data files is less straightforward. A data file attack requires specific knowledge of the file format(s) involved, and how the application uses that data. However, it is not impossible. For example, successful exploits have used malformed image files to cause buffer overruns in image-handling libraries on various platforms, and malformed document files against various productivity applications and suites. In general, the more well-known the file formats (and application vulnerabilities) the more likely they are to be exploited. However, targeted attacks can be mounted against any vulnerable application.

It is always best to avoid loosening access control on shared resources whenever possible. So always consider:

  • Does the application really need access to that object? For example, if the application can't write to a log file it maintains in its application folder, does the application continue to work correctly anyway? If so, then it's not a true LUA bug, so don't try to fix it.
  • Is the data file accessed through the "Ini File" APIs? If so, an IniFileMapping entry might fix the problem by redirecting access to per-user registry keys. For this reason, LUA Buglight [URL coming soon!] distinguishes "Ini File" API access separately from file access issues.
  • The LUA shims of the Application Compatibility Toolkit may obviate the need for any access control changes.
  • [and other mitigations described in the earlier "Fixing LUA Bugs" posts.]

As mentioned, given the choice between loosening access for a file or for its containing folder, it is always preferable to do so for the file. However, if the file does not already exist, the application will need permission on the containing folder to create the file – you can't set permissions on an object that doesn't exist. You may be able to get around this issue by pre-creating the file and setting the necessary permissions on it. If it turns out that the application regularly deletes and then re-creates the file, a further trick that might work is to pre-create the file and grant the application user the ability to write to the file, but not to delete it. Many apps won't bother to verify that the deletion succeeded, and will clear the contents of the file on subsequent access anyway. These tricks will not work, however, for cases where the application creates a temporary, randomly-named file for edits, then deletes the original and renames the temporary file to the name of the original.

In summary:

  • Changing access control on shared resources should be avoided if at all possible – investigate alternatives first.
  • Grant the least amount of additional access to the smallest possible number of resources.
  • Loosening access on specific data files is greatly preferred to loosening access on folders.
  • Avoid loosening access on executable code files.