Fixing "LUA bugs", Part I


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 (52)

  1. 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

  2. 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".

  3. John C. Kirk says:

    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…

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

  5. Alun Jones says:

    Can we carve this blog entry in stone tablets and drop it on Intuit, please?

  6. Dan Mc says:

    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.

  7. Mike Stoltzfus says:

    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.

  8. Small Potato says:

    Thanks Aaron. Your tips are really, really helpful.

    Now virtually all my installed applications run in LUA flawlessly.

  9. Complete list of Aaron Margosis’ non-admin / least privilege posts, for easy lookup.

  10. John Bokma says:

    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 🙁

  11. Jamie Anderson says:

    @ Henning Krause

    Believe it or not, the developers were writing to Microsoft’s coding guidelines. These guidelines state that an application and all of its data (except user-specific data) must be stored in the program’s directory under Program Files.

    The developers here are just following the guidelines. As the database is a shared resource (not user-specific), it must be placed in the program’s directory.

    I haven’t looked at the guidelines in a while, but I wonder whether they’ve been revised for LUA? Things like this are the biggest issue.

    Note: In this case, the correct thing probably would have been to give the MDB file write permissions for certain users. However, that then allows any of those users to write whatever they like to the file, even to overwrite it with invalid data.

    For security, it would have been better to use a back-end data store managed by another process, running under a special user account. All access to the data would have to be through that process, which can check for validity and help prevent malicious activity.

  12. Thomas Goodman says:

    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 http://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.

  13. Freddie says:

    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!

  14. Alex Haines says:

    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 😀

  15. The CPU says:

    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

  16. Those of you who are taking advantage of the Remote Access Quarantine feature of Windows Server…

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

  18. Richard Cass says:

    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

  19. Richard Cass – yes.  Protection Manager will be mentioned in Fixing LUA Bugs, Part II, which I am still working on!

  20. On the Security 360 webcast that was on earlier today, the topic was on "browser hardening". …

  21. So you want to try this "non admin" thingy I keep harping about but you have this application that updates…

  22. A systematic approach for working around LUA bugs that avoids unnecessary exposure – "the rest of the story"

  23. Suite (et fin ?) des articles d’Aaron Margosis…

    Ces articles sont en anglais, mais fournissent énormément…

  24. -=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

  25. Richard Francis says:

    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 ?

  26. Wes Miller (Winternals) says:

    Richard (Francis) – would it be possible to speak with you? I’d like to hear about your experience with Protection Manager to see what problems you have run into. We designed it to be pretty easy to get up and running, so if you are still not able to get it running, I’d like to see if I can help you get it working.

  27. Matt Jessick says:

    Per #1 above

    I’ve been "trowl-ing" 😉 through pages trying to figure out how to update my application to become WinXP LUA and Vista UAC compliant.

    It is my understanding that app output files that users may want to see and possibly change should be written to CSIDL_PERSONAL type folders (e.g.: My Documentsmy_app_name ).

    For example, this advice: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Gaming_with_Least_Privileged_User_Accounts.asp

    What I’m suddenly wondering is what happens once we nonsensical 😉 developers have all completed "Part I #1" above… and users suddenly see 50 new folders appear in their My Documents folder.

    Has anyone researched this aspect? The whole My Documents folder raises my blood pressure alarmingly 😉  everytime a file dialog starts there (I assume I’m in the minority here). But what about the people that actually _like_ My Documents: now THEY have to page past many new entries just to find their recipe database.

    I’m tempted to write ALL my UAC/LUA app data to the hidden CSIDL_LOCAL_APPDATA type folder, e.g.: C:Documents and Settingsmy_user_nameApplication Data

    just to avoid this possible backlash (whether the users might ever want to edit a saved file or not.)

    I’ve been bitched at before by irate users infuriated that I wrote anything at all to their C: Drive. I can hardly wait until they see me polluting their My Documents folder…

    At the least, I’m probably going to create a single folder in My Documents for our company, rather than one per app.

  28. 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."

  29. Joeb says:

    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?

  30. Joeb:  Games are some of the biggest LUA offenders there are.  With some of them, option #3c above (updating SafeDisc) is all you need.  With others, you may have to go down to option 5 (run that one app as admin) – and that may not work either.  And even if it does – even if you can run the game as admin while your desktop is LUA – you need to realize that the game is exposing your whole system.  From what I’ve heard, games are usually written in C or C++ and often have exploitable buffer overflows that never get patched.  Internet-connected games offer up that BO to other gamers, if not to the entire internet.  And if that BO is exploited, the injected code will run as admin.  Very bad news.  What it comes down to is that you need to look carefully at the risks involved and your exposure.  If playing the game were really important to me, I would probably go ahead and just run as admin, BUT only on a machine that:

    1) holds *nothing* else of value (docs, pictures, email, personally identifiable information, etc.);

    2) is not connected to any network (home or work) that holds anything of value; and

    3) I don’t mind the hassle of running FDISK and reinstalling Windows regularly.  Just assume you’re getting hacked through that game.

  31. michelle says:

    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.

  32. zzz says:

    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?

  33. More info on the risks of changing access control lists to fix LUA bugs.

  34. "Why does Application XYZ need to run as admin?"

  35. Hans says:

    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?

  36. 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.

  37. One way of coping with the challenges corresponding with "the principle of least administrative privilege"

  38. On the second Tuesday of the month Microsoft introduces updates for it's products. As a system administrator

  39. Mark Reynolds says:

    Microsoft’s Best Practices Guide says to use CSIDL_COMMON_APPDATA for info that is run time changeable for all users on a box. This maps to ProgramData directory on Vista. Why is the security set on that folder to be inherited so that Users have no rights to write to subfolders?

    MS says this is the place for common data!

  40. More info on the risks of changing access control lists to fix LUA bugs.

  41. A systematic approach for working around LUA bugs that avoids unnecessary exposure – "the rest of the story"

  42. One of the reasons that people kick and scream about Vista is that they have been "ADMIN" for

  43. MVPs says:

    One of the reasons that people kick and scream about Vista is that they have been "ADMIN" for

  44. Petter Hesselberg says:

    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.

  45. Petter Hesselberg says:

    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.

  46. Petter Hesselberg says:

    Reades -> reads. Duh.

Skip to main content