Udostępnij za pośrednictwem

Fixing "LUA bugs", Part I

  • Artykuł

You have an application that you – or your users – need to run. It’s a normal app – it isn’t designed to perform system administration of your computer, but for some reason, it doesn’t work correctly unless it’s run from an account that has administrator-level access (see “What is a "LUA Bug"? (And what isn't a LUA bug?)”. But you don’t want your users running as admin. What to do?

The “workaround” most frequently chosen is simply to add the user to the Administrators group. Sometimes this approach is not decided by the IT department, but by some “helpful” HelpDesk technician: “Let’s see whether this fixes the problem.” The technician forgets to remove you from the Admins group, inevitably leading to another HelpDesk call within a few weeks: “HelpDesk, why is my computer running so slowly, and why are all these porn ads popping up whenever I log on?” (Answer: Because you’ve been running as admin!) Let’s just call this “workaround” a non-starter and not give it any further consideration.

Other common but sub-optimal workarounds are: 1) run the one program as administrator, or 2) run the program as a regular user, but after granting Everyone “Full Control” over the program’s installation folder and all of its registry keys under HKEY_LOCAL_MACHINE, and to all of HKEY_CLASSES_ROOT. Oh, and while we’re at it, grant the user the “Debug”, “Take ownership” and “Act as part of the operating system” privileges. These are seriously high-risk ways to get the program to run, and should be avoided.

So what do you do? In this mini-series of posts, I’ll lay out a systematic approach for working around LUA bugs that minimizes exposure. I’ll discuss approaches from most-preferred to least-preferred, with some of the pros and cons of each. By the way, while this guidance is targeted primarily to Windows XP, it will also work on Windows Vista.

#1: It is a bug – treat it like one and make the developers fix it!

This is the most preferred approach. If there is no legitimate business or technical reason for the app to require admin privileges, then failure of the app to work for a regular user account is a serious bug that compromises system security, stability and manageability. (Note: if the development team says something like “It’s mission-critical, so it has to run as admin”, or “it writes to HKEY_LOCAL_MACHINE, so it has to run as admin”, the correct response from you is, “You’re talking nonsense. Fix the bug!”)

Benefits of this approach:

  1. Once it is fixed this way, you don’t need to carry forward any shims, tweaks or workarounds.

  2. Developers may learn from the experience, and stop creating new LUA bugs. (Note: Developers running as admin are the #1 cause of LUA bugs!)

There are some drawbacks, though:

  1. The expense in time and/or money may be prohibitive, particularly if you have limited resources and a lot of apps to fix. You have to consider the possibility of the app having to be rearchitected, and the possibility of new bugs being introduced in the process.

  2. The developers and/or the source code may not be available. It may be 3rd party code from a company that no longer exists. The developers may be in rehab. Or jail. Or working for your competitor. Or they may be working on something “more important”.

#2: Application Compatibility Toolkit

Use the LUA Mode shims of the Application Compatibility Toolkit (ACT). (File and Registry Virtualization is the equivalent solution built into Windows Vista.)

The LUA Mode shims detect attempts to write to system-wide locations in the file system and registry and silently redirect them to per-user locations.

Benefits of this approach:

  1. It is easy to implement

Drawbacks:

  1. The LUA Mode shims on XP often do not work (Vista’s Virtualization is a complete rewrite and will have much higher compatibility marks than XP’s ACT LUA Modes.)

  2. The added complexity of the resulting underlying operations can make your troubleshooting more complicated when things don’t work.

The next 3 items (3a, 3b and 3c) are system changes that solve different specific issues, but share the common feature of not granting any elevated access to system-wide resources.

#3a: Copy specific HKCR keys to HKCU\Software\Classes

(Registry notations used here:

HKLM = HKEY_LOCAL_MACHINE;

HKCR = HKEY_CLASSES_ROOT;

HKCU = HKEY_CURRENT_USER)

Some background:   Prior to Windows 2000, HKCR was just a symbolic link to HKLM\Software\Classes, which only Administrators can write to. In other words, operations performed on HKCR\.txt would actually occur in HKLM\Software\Classes\.txt. Windows 2000 introduced per-user registration data, so now HKCR is a merged view of HKLM\Software\Classes and HKCU\Software\Classes (which the user can write to). If a key exists in the latter, it takes precedence. So now an operation on HKCR\.txt will occur in HKCU\Software\Classes\.txt if that key already exists, otherwise it will occur in HKLM\Software\Classes\.txt as it had in the past.

The issue to fix:   A number of applications write to HKCR at runtime to “reinforce” their file associations, COM registration data, etc., and raise an error if the write fails, even if the data they want to write is already there. The same data is written every time the app runs. If that same registration data were stored in HKCU\Software\Classes, then the write operations would succeed, without changing program behavior.

How to fix it:   First you must identify the keys under HKCR that the application is trying to write to. (How to do that will be covered in later posts.) Export those keys to one or more .reg files (in Regedit, use File/Export, Selected branch). Using a text editor, replace all instances of

[HKEY_CLASSES_ROOT\

with

[HKEY_CURRENT_USER\Software\Classes\

and save your changes. Import the edited .reg file into the registry of the user who needs to run the program.

Benefits of this approach:

  1. This fixes issues where applications perform operations in HKCR that should have been done only during installation.

  2. This approach is better than loosening access control on system-wide resources under HKCR (HKLM). Malware overwriting keys under HKCU will not affect operating system components or other users of the computer.

Drawbacks:

  1. It is not easy, with today’s tools, to identify HKCR writes as the source of LUA bugs, and exactly which keys are involved. (More on this in upcoming posts.)

#3b: IniFileMapping

Background:

Back in the days of Windows 3.x, before there was the Registry that we know and love, the OS and applications stored configuration and preference data to .ini (initialization) files, such as win.ini. Windows did and still does offer API-level support for .ini files via the “Profile” APIs (e.g., WritePrivateProfileString). Many apps (including some Windows applets) still use these APIs to try to write to .ini-formatted files, often in folders where Users are not supposed to write.

Windows NT 3.1 encouraged the migration from .ini files to the more scalable and manageable Registry, and provided a means for automatically redirecting .ini file reads and writes to registry keys. The internal implementation of the “Profile” APIs was augmented to use mappings found under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\. If a mapping for a .ini file is not found under that key, then the operation is performed in the file system as before.

The issue to fix: If access to an .ini-formatted file – via the “Profile” APIs – is the cause of a LUA bug, it can be remediated by adding a key under the IniFileMapping key to redirect access to HKCU. Note that IniFileMapping is under HKLM and requires administrative privileges to configure. The config specifics are described in the documentation for the “Profile” APIs, such as WritePrivateProfileString.

Benefits of this approach:

  1. This approach is better than loosening access control on system-wide resources in the file system. Malware overwriting keys under HKCU will not affect operating system components or other users of the computer.

Drawbacks:

  1. It is not easy, with today’s tools, to identify .ini-file access as the source of LUA bugs. (More on this in upcoming posts.)

#3c: SafeDisc

A number of games depend on the “secdrv” device driver, also known as “SafeDisc”, from Macrovision. The secdrv driver that ships with Windows XP is a demand-start driver, which users are not allowed to stop and start, resulting in errors when accessed by programs. There is an update, available from Microsoft and from Macrovision that configures the driver to be loaded when the system starts so that the user does not need to start it. This change allows some games to work correctly for a non-admin user.

(Note that as of this writing, the Microsoft download page for this update says that “[t]his software will not alter or patch any component on your system, it will only change the startup state of the system component…” This is actually not true – it installs an updated driver.)

Benefits:   Easy to implement, and no ACL changes to systemwide resources.

Drawbacks:   None, really.

Coming up in Part 2:

#4: Loosening specific ACLs, and

#5: Running the one app as admin

Comments

  • Anonymous
    February 15, 2006
    Hello Aaron,

    your solution #1 is indeed the best one. But last time I called support for an online-banking application becuase the software needs write access to an access database in its program files folder, the support team just said: We need that access. Period. There are just too many developers not aware of this LUA thing right now...

    Henning

  • Anonymous
    February 16, 2006
    Henning - you are absolutely right.  This is where the "You are talking nonsense!" response applies.  Unfortunately, it doesn't mean you'll win.  "The developers may be shrieking baboons" should be added to the second item under "drawbacks".

  • Anonymous
    February 16, 2006
    I don't remember what the application was off-hand, but there was one case where I emailed the developers to report a bug, and they wound up saying "We can't imagine anyone not running as administrator". I suggested that they should read Michael Howard's book ("Writing Secure Code"), and I never heard back from them after that...

  • Anonymous
    February 16, 2006
    Aaron has started a series on how to fix LUA bugs. If you read his article on “What is a "LUA Bug"? (And what isn't a LUA bug?)" and want to learn how to fix your code, this is a good place to start....

  • Anonymous
    February 16, 2006
    Can we carve this blog entry in stone tablets and drop it on Intuit, please?

  • Anonymous
    February 16, 2006
    Haha!  Intuit apps are just horrible about this.  I swear they use randomly generated guids at runtime.  I granted users read/write to about 200 guids under HKCR that I found Quickbooks accessing.  The next time it ran, it promptly tried to create or access 100 more.  Same with the way it prints.  It tries to enum the Windows printers and build it's own print dialog.  (The only visible difference from the Windows print dialog is that they put a preview button on the pring dialog.)   It choked on http:// printers because it was trying to add \ in front to create a UNC path.

  • Anonymous
    February 16, 2006
    Ditto on the Intuit woes!  Isn't there anything Microsoft can do to get them to clean up their act?  I've called them on this numerous times, and the only people they let me speak to are people who have no concept of what I'm talking about.

  • Anonymous
    February 16, 2006
    Thanks Aaron. Your tips are really, really helpful.

    Now virtually all my installed applications run in LUA flawlessly.

  • Anonymous
    February 16, 2006
    Complete list of Aaron Margosis' non-admin / least privilege posts, for easy lookup.

  • Anonymous
    February 16, 2006
    http://johnbokma.com/mexit/2005/11/09/irfanview-ini-fix/comments.html describes a LUA bug, and my attempts to convince the author of IrfanView to fix it. His reply was that I was the first one complaining about it :-(

  • Anonymous
    February 16, 2006
    The comment has been removed

  • Anonymous
    February 16, 2006
    PingBack from http://blog.appelgren.org/2006/02/17/fixing-lua-bugs-article/

  • Anonymous
    February 17, 2006
    I've been a long time reader of Aaron's blogs.  I too strugle regularly with vendors and them saying the app needs the user to be an admin.  So far with the aid of Filemon and Regmon from www.systernals.com I've been able to open the correct program file folders and registry keys for about 99.9% of the apps. We usually add them to our Active Directory GPO and have them apply to all machines so we don't have to manually make the exceptions each time.

    You can tell the vendor that all it needed was access to this file or reg key but they seem to care less.  I'll just have to keep working around them.  Granted we are starting to see more of the apps to be a little more friendly, I still get frustrated at the ones that haven't a clue.

  • Anonymous
    February 20, 2006
    Thanks a lot!  For the longest time, my files had the wrong icon in explorer on my LUA account, but not my admin account.  #3a worked to fix this!

  • Anonymous
    February 22, 2006
    Can anyone (Thomas Goodman?) point me in the direction of a good guide while using filemon and regmon to make porgrams work with lua bugs? If there is going to be one on this blog soon - then sorry I'll wait but I need it sooner than later please :D

  • Anonymous
    February 27, 2006
    I've posted a question to ms.appcompat newsgroup about using the LuaFS shim, but no answers so far. I am trying to understand how to configure the LuaFS shim (ACT4.1), to redirect writes to windows directories. I am testing with Paint.exe and Notepad.exe but it does not seem that its doing anything. If I create a file and try to save to windows, the dialog says I don't have permissions.

    I have run the ACT admin tool, specified the directories, installed the db. Any clue?

    You also mention that the Lua impl for XP fails in some cases? can you tell me what cases?

    CPU

  • Anonymous
    March 06, 2006
    Those of you who are taking advantage of the Remote Access Quarantine feature of Windows Server...

  • Anonymous
    March 08, 2006

    In today’s Webcast we first started off with a continuation from last week.  Last week we explored...

  • Anonymous
    March 09, 2006
    Have you looked at the Winternals Protection Manager?
    Although I have not, it appears to offer the opportunity to move users from the local admin group.

    http://www.winternals.com/Products/ProtectionManager/Default.aspx

  • Anonymous
    March 09, 2006
    The comment has been removed

  • Anonymous
    March 21, 2006
    On the Security 360 webcast that was on earlier today, the topic was on "browser hardening". ...

  • Anonymous
    March 26, 2006
    So you want to try this "non admin" thingy I keep harping about but you have this application that updates...

  • Anonymous
    March 27, 2006
    A systematic approach for working around LUA bugs that avoids unnecessary exposure - "the rest of the story"

  • Anonymous
    March 27, 2006
    Suite (et fin ?) des articles d'Aaron Margosis...
    Ces articles sont en anglais, mais fournissent énormément...

  • Anonymous
    April 03, 2006
    -=Daily DisInfo 030406=- Ancora sul Desktop 3DLa presentazione della tecnologia Xgl da parte di Novell per una rappresentazione tridimenzionale del desktop ha suscitato molto scalpore. Forse però non tutti ricordano che la Sun Microsystem gi&ag

  • Anonymous
    April 26, 2006
    In refernce to the wininternals protection manager.

    I have found it very difficult to get it working let alone achieve anything especially in a large organization, are there any other GPO tools that you can review and recommend in Part II ?

  • Anonymous
    April 26, 2006
    The comment has been removed

  • Anonymous
    May 11, 2006
    The comment has been removed

  • Anonymous
    May 11, 2006
    Matt Jessick - good question.  As you suggest, the CSIDL_PERSONAL folder is highly exposed to end users, and is intended for documents and other objects they will want to access directly (see also CSIDL_MYMUSIC, _MYPICTURES, _MYVIDEO).  It sounds as though you need one or both of CSIDL_APPDATA and CSIDL_LOCAL_APPDATA.  These are for application data folders/files.  The contents of CSIDL_APPDATA are "roamable"; CSIDL_LOCAL_APPDATA is for "non-roamable" data.  (On US English systems, these map to "Application Data" and "Local SettingsApplication Data".)
    See
    http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx, 3.0 Data and Settings Management: Requirements Summary:  "User-created files must be stored in the user's My Documents (or descendant) folder....  Application data, such as user preferences, application state, temporary files, and so on, must not be stored within My Documents."

  • Anonymous
    May 23, 2006
    What about games copy protection that needs admin to run or thing like punk buster that needs to run as admin or you can't play. What about games that update them self’s in game?

  • Anonymous
    May 23, 2006
    The comment has been removed

  • Anonymous
    May 26, 2006
    don't understand  why when i plugged in the question" Having trouble with internet explorer 6.0 service pk 2 for windows XP. every time I go to click it it says 'Run time error'"  When I plugged that in your site came up.  Trying to figure out this problem with IE 6.0  can any one help?  please email me at Pookie20852@yahoo.com   Have had to use netscape because i can't access Ie at all.  have tried to down load updates hasn't worked.  it updated but the problem didn't reslove.

  • Anonymous
    May 29, 2006
    PingBack from http://www.tedroche.com/blog/?p=1957

  • Anonymous
    June 01, 2006
    Aaron, I do not see what the issue is with games and security? The hyped hypervisor technology should perfectly well allow run the game with native speeds but virtualized from the rest of the system, Right?

  • Anonymous
    June 19, 2006
    More info on the risks of changing access control lists to fix LUA bugs.

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

  • Anonymous
    August 25, 2006
    Although you state that using the Application Compatibility Toolkit is easy to implement, I don't have a clue how to perform this. Can you give some brief hints and guidelines?

  • Anonymous
    August 28, 2006
    Re: Using Application Compatibility Toolkit - the tool from ACT that you want to use for applying shims is CompatAdmin. CompatAdmin will show you any existing shims on the installation (the system SDB, or Shim DataBase), and you can create a new SDB. Tell CompatAdmin to create a new fix, select the executable, select the shim or layer (a layer is just a collection of shims), and you will generate a custom SDB. This custom SDB will be installed locally. To deploy this custom SDB, use %windir%system32sdbinst.exe. You can make a single SDB with all of the shims you need for the applications in your organization, updating it as required.

  • Anonymous
    September 05, 2006
    One way of coping with the challenges corresponding with "the principle of least administrative privilege"

  • Anonymous
    September 05, 2006
    On the second Tuesday of the month Microsoft introduces updates for it's products. As a system administrator

  • Anonymous
    October 27, 2006
    The comment has been removed

  • Anonymous
    November 02, 2006
    PingBack from http://blog.donnael.com/?p=1318

  • Anonymous
    February 15, 2007
    More info on the risks of changing access control lists to fix LUA bugs.

  • Anonymous
    February 15, 2007
    A systematic approach for working around LUA bugs that avoids unnecessary exposure - "the rest of the story"

  • Anonymous
    March 27, 2008
    One of the reasons that people kick and scream about Vista is that they have been "ADMIN" for

  • Anonymous
    March 27, 2008
    One of the reasons that people kick and scream about Vista is that they have been "ADMIN" for

  • Anonymous
    December 20, 2010
    I've just been working over a program with a HKEY_CLASSES_ROOT problem, and it struck me that one detail needs to be stressed: While writes to HKEY_CLASSES_ROOT should be redirected, to HKEY_CURRENT_USERSoftwareClasses, reades should not.

  • Anonymous
    December 20, 2010
    I've just been working over a program with a HKEY_CLASSES_ROOT problem, and it struck me that one detail needs to be stressed: While writes to HKEY_CLASSES_ROOT should be redirected, to HKEY_CURRENT_USERSoftwareClasses, reades should not.

  • Anonymous
    December 20, 2010
    Reades -> reads. Duh.