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:
… 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:
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:
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.