Delen via

Changing access control on folders vs. files

  • Artikel

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.

Comments

  • Anonymous
    June 19, 2006
    PingBack from http://blogs.msdn.com/aaron_margosis/archive/2005/04/18/TableOfContents.aspx

  • Anonymous
    June 19, 2006
    It is sometimes difficult to find out what files a program needs to write to. Filemon may help.

  • Anonymous
    June 21, 2006
    I orginally had an account on my computer named "Ajay" that was an administrator.  Then I changed it to a LUA account and much of my exisiting software seemed to work fine.  Then I figured out why - all the software that was installed in "C:Program Files" while I was an admin had "Ajay" as the owner of the folder so I still had full control even though "Ajay" is now a Limited User.  I discovered this when Yahoo Music Engine installed an update to itself and I thought = "Huh? I shouldn't be able to do that."  

    By the way, program that use Access databases in their program files folder dynamically create and delete a *.ldb file in the same folder.  The *.ldb is only needed if you want to allow multiple applications to open the same database. That's the "Default owner" setting at work.  See my post about that issue here. -- Aaron

  • Anonymous
    August 07, 2006
    "Why does Application XYZ need to run as admin?"

  • Anonymous
    September 21, 2006
    Oh well,- if hardlinks and junction points could include late evaluated enviroment variables like:
     fsutil hardlink create "C:Program FilesVendorXInfoX.dat" "%%USERPROFILE%%Application DataVendorXInfoX.dat"
    some of the problems could be worked around. It wouldn't, though:  both copies would have the same ACL.  If you're loosening access control on either copy, you may as well just keep the one shared copy. -- Aaron

  • Anonymous
    September 22, 2006
    Yeah of course, - hadn't thought of that.
    What I wished for was a new kind of link type different from both hard and symbolic links (e.g. linux/fs3) that could point to different places based on current user.
    Btw. Aren't MS playing around with something similar (some kind of transparent redirection from Program FilesVendorX and HKLMsoftwareVendorX) in Vista to keep the combatibility with 'elderly' programs ? You're probably thinking of file and registry virtualization.  Not really the same thing - for one thing, it's not implemented in the file system, the way hard links are. -- Aaron

  • Anonymous
    September 22, 2006
    Yeah that was what I was thinking of.
    No not the same thing but the same but effect though. Still transparent to applications.

  • Anonymous
    September 22, 2006
    But of course, as I understand with regard to the file and registry virtualization, the attacked user will still be vulnerable to DLL redirections etc. but other users won't be affected though as in the folder privilege elevation scenario. DLL redirections shouldn't be a problem -- Vista's file virtualization is not applied to executables (.exe, .dll, .ocx, etc.). -- Aaron

  • Anonymous
    September 22, 2006
    Btw Aaron
    OT
    Just want to thank you for all those excellent articles about LUA . Have been running in LUA mode since the start of 2005, IRC, (of course only possible through the advices from your blogs :) ), after I read an article about the subject in the German Computer Magasin C'T http://www.heise.de/ct/04/15/106/default.shtml

    Henrik

  • Anonymous
    November 02, 2006
    The comment has been removed

  • Anonymous
    February 15, 2007
    Updated information about LUA Buglight.

  • Anonymous
    August 16, 2007
    One of my biggest gripes since switching to Vista and dealing with UAC is the lock down of 'all user' program shortcuts that are now stored in C:ProgramDataMicrosoftWindowsStart MenuPrograms (which took the place of, I think, C:Documents and SettingsAll UsersStart MenuPrograms in XP).  I install a lot of programs and my Start Menu eventually begins to look like a jungle.  I create a hierarchical folder tree of program shortcuts to keep the Start Menu | All Programs list under control, moving shortcuts around almost every time I install a new program.  This became a headache with Vista interrupting me with demands for elevated access at every turn, so I elevated my permissions for this area. This is the only folder tree for which I have (or intend to) reset permissions to add full access for my own account.  The changed permissions start at the Programs folder level, not at Start Menu or anywhere above.  I can't really see the harm - as these folders contain nothing but shortcuts - but is there a vulnerability in these folders of which I'm not aware? [Aaron Margosis] Well, there are certainly much worse things you could have done. :-)  And moving those shortcut files around would certainly lead to a lot of prompts.  The risk in opening up those permissions is that now anything running as you can change where the links point to.  E.g., malware can drop a binary somewhere in the file system and point the Word or Acrobat links to it (or point all of the links to it).  This is low risk for you (since if malware's running as you it can do similar stuff anyway), but adds risk for other users on the computer.  Now anyone starting a program through any of the Start Menu links can end up running malware instead. Check out this blog post and see whether it can help you get an Explorer window running elevated so that you can move these shortcut files around without incurring prompts. Hope this helps.

  • Anonymous
    August 28, 2007
    The comment has been removed

  • Anonymous
    December 13, 2007
    ,re: Changing access control on folders vs. files,alexander,,I have 2 applications that creates temporary files (randomly named) in windows and system32 respectively. The solution that i can think of is to give the users permission to "create files/write data" that applies to "this folder only". Is it safe? [Aaron Margosis]  No.  Can you get these applications replaced or rewritten?  Can you upgrade to Vista?  On Vista, these file writes and subsequent reads will be transparently redirected to a location in the user's own profile ("file virtualization"), so the app will work correctly without the user having to be granted excessive permissions in a system-wide file location.