Welcome to MSDN Blogs Sign in | Join | Help

Chris Jackson's Semantic Consonance

Windows Application Compatibility in the Real World

News

  • Chris Jackson is an Architect and the Technical Lead for the Windows Application Experience SWAT Team.

    This is provided "AS IS" with no warranties, and confers no rights. Use of materials found on this page is subject to the terms specified in the Terms of Use

Per-User COM Registrations and Elevated Processes with UAC on Windows Vista

Last time around, we looked at an application compatibility side-effect of User Account Control on Windows Vista: the potential impact on Mapped Network Drives when running elevated. Another side-effect that may affect application compatibility is the changes we have made around per-user COM registration.

Back in Windows NT 4.0, HKEY_CLASSES_ROOT was simply an alias of HKEY_LOCAL_MACHINE\Software\Classes. However, beginning with Windows 2000, HKEY_CLASSES_ROOT is a merged view of the data in HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. Aaron Margosis discusses how to leverage this merged view (and the differences in permission) to resolve LUA bugs in his Technet article Problems of Privilege: Find and Fix LUA Bugs. You see, when we search for a COM registration, entries in the HKEY_CURRENT_USER hive take priority.

And it is exactly this property (fixing LUA bugs) that makes this load behavior dangerous if your process happens to be elevated. A standard user is able to write to these registry entries, which is why it can help applications to work. Because a standard user can write the configuration for a COM object, we don't want to open the door to an elevation of privilege attack. If we simply enforced the same rules for an elevated process, loading entries from the user hive first, then a process could easily write a new configuration for a commonly loaded COM object, point the configuration to arbitrary code, and have an elevated process pick up that arbitrary code, executing it with administrator privileges! Consequently, we block loading of COM registrations from the per-user registry hive if the process' integrity level is higher than medium. That means you won't pick up a per-user COM object if you are manifested as requireAdministrator, or if you have manually elevated the application (right click - Run as Administrator). It also means you won't pick up a per-user COM object if you are running as a member of the local Administrators group and you have disabled UAC for some reason.

So, if you are an application developer who is designing an application to run elevated, you should make sure that you drop your COM registrations in the per-machine hive (which creating a new key in HKCR will do by default) at install time, rather than relying on a per-user installation.

Posted: Wednesday, February 21, 2007 9:32 AM by Chris Jackson
Filed under:

Comments

amar1223 said:

"means you won't pick up a per-user COM object if you are running as a member of the local Administrators group and you have disabled UAC"

Doesn't seem to follow this after updating to SP1.

On my Vista Business SP1, running as an admin with UAC disabled, my program picks up COM registered to HKCU.

This was working fine - as described before installing SP1.

Is this intentional?

# June 3, 2008 2:51 AM

Chris Jackson's Semantic Consonance said:

A while back, I was talking about per-user COM registration and elevated processes on Windows Vista .

# June 6, 2008 2:27 PM

Chris Jackson said:

Hi Amar,

Rather than leaving this buried in comments, I addressed this in a full post here:

http://blogs.msdn.com/cjacks/archive/2008/06/06/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista-sp1.aspx

Sorry about the confusion!

Chris

# June 6, 2008 2:29 PM

Jerry said:

Please help me to adress this issue when i try to run stadarad user anlyzer in a user login i am gettin this error in details of "unhandled exception elevation required"

# June 19, 2008 11:35 AM

Chris Jackson said:

Hi Jerry,

So we can get somebody to track down your problem, let's get you over to a newsgroup so you have more than just me working on it. The ACT team monitors this newsgroup, so we'll be able to get more resources helping you out.

You can find it at http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.deployment.app_compatibility&cat=en_US_BFF781FD-77D8-BFD2-4429-5A9D175157BF&lang=en&cr=US

Good luck!

Thanks,

Chris

# June 19, 2008 12:05 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker