Per-User COM on Vista for elevated token processes


Per-user COM in Vista (where CLSIDs, etc. go under HKCU\Software\Classes instead of HKLM\Software\Classes) behaves different on Vista compared to XP. Actually it does not work at all for full administrators (to be precise, it is actually for any process with a MIC level higher than medium but more on that later). The CoCreateInstance or CreateObject call will return 0x800A01AD (-2148139437 or “server can’t create object” or REGDB_E_CLASSNOTREG).


The reason that it is not working is – you guessed it – a security issue. Non-elevated administrators are standard users and they can write to HKCU and hence \Software\Classes to their hearts content. So it would allow them to add entries to the registry that a process running under a full administrator token then would read.


Imagine the scenario where a rogue COM component is registered under HKCU by a non-elevated administrator process. There is no need for a consent dialog since again, standard users can write to HKCU. When a program is running as full administrator it could load the rogue COM dll under its all too powerful admin token in its process space. This is a schoolbook example of elevation of privilege. It is also going against the basic premise of UAC that anything running on the machine as administrator has to be installed and approved by an administrator.


Thanks Saji and Riyaz for helping me on this.


Maarten

Comments (3)

  1. Frank Kang says:

    Maarten, thanks a lot for the explanation as this specific scenario is one that I had not been able to find much information on.

    The rationale for this policy makes a lot of sense when UAC is enabled. However it doesn’t seem to me that it has any benefit when UAC is disabled. Because in this case, an admin user is always elevated so elevation of privilege has no bearing here. Worse, this breaks backwards compatibility with previous versions of Windows.

    Ideally, wouldn’t this restriction for per-user COM be enforced only when UAC is enabled so that backwards compatibility is maintained when possible?

    Frank Kang

    ClearContext

  2. Coffee Plant says:

    Ah, well, that’s all making more sense 🙂

    I’m trying to get our universal game engine to play nicely under Vista and we had a problem with IID_DirectMusic8 not being instantiated … it fails with REGDB_E_CLASSNOTREG. This is code that’s worked fine under 95, 98, Win2K and XP so I’m a bit baffled as to what I’ve done wrong or what I do to fix it. I understand that DirectMusic is indeed supported.

    Sorry to sound monumentally stupid, but what should I do to make everything lovely and happy again? I hate to see a sad computer.

  3. I’m desperately trying to get a managed BHO to interop with my IE Broker. The Broker should be a Remoting