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:

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

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:

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.

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:

It is easy to implement

Drawbacks:

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

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\.txtif 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:

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

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:

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:

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:

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.

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

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…

Aaron has started a series on how to fix LUA bugs. If you read his article on What is a &quot;LUA Bug&quot;? (And what isn’t a LUA bug?)&quot; and want to learn how to fix your code, this is a good place to start….

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.

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.

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.

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.

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 😀

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?

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.

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.

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

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:

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.

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?

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.

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?

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.

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.