Vista Compatibility Team Blog : Windows Vista Application Compatibilty XP port

Mark and Manmeet on .Net Show

VistaCompatTeam — Tue, 24 Oct 2006 19:09:00 GMT

Mark and Manmeet appeared on the .Net show last week. Enjoy:

http://msdn.microsoft.com/theshow/episode.aspx?xml=theshow/en/episode059/manifest.xml

Maarten

rundll32.exe appwiz.cpl,NewlInkHere is back

VistaCompatTeam — Fri, 20 Oct 2006 23:44:00 GMT

For some reason it was quite common to use an undocumented (and hence unsupported and we-can-pull-rug-underneath-at-any-time) export from the appwiz.cpl called newlinkhere. This export was removed in Vista. Since this was quite a popular export (live.com for it yourself, you’ll see) we decided at a late stage to put it back in. I haven’t verified it but it should be in the RTM version. You would use it like this:

rundll32.exe appwiz.cpl,NewlInkHere

Maarten

Impact of Least Privilege in System Services

VistaCompatTeam — Thu, 19 Oct 2006 20:31:00 GMT

Of all security changes in Vista, UAC with its spit token and MIC is for obvious reasons getting most attention. But there are a lot of other areas that have been tightened up for security reasons and we keep finding new ones that impact customers. One of them is detailed in the document on service changes in Vista. The specific session is called Running with Least Privilege.

In Vista you can have NT services explicitly have only the privileges they need. You can view them with "sc qpriv" or just go to the registry (HKLM\SYSTEM\CurrentControlSet\Services under RequiredPrivileges). This is a good thing because you no longer have to get all the other privileges that for example Local System has if you only need one or two. For example "sc qprivs rpcss" will give you only three privileges on Vista.

As with pretty much any change, there are impacts. For example, if your MSI package had a custom action (CA) that was assuming the Windows Installer service had the SeBackupPrivilege, you will be unpleasantly surprised. Checking it with "sc qpriv msiserver" shows that SeBackupPrivilege is no longer there. This was done to reduce the attack surface of the Windows Installer service.

Let us know if this or another service missing a privilege is impacting you.

Thanks to Christopher for pointing this out.

Maarten

Per-User COM on Vista for elevated token processes

VistaCompatTeam — Tue, 17 Oct 2006 20:28:00 GMT

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