Crash when trying to run non-elevated from an elevate process

[enricogior]

Description

PowerToys needs to start a .NET Core application with non-elevated privileges from an elevated process.

We tried two different approaches, they both resulted in this crash report:

Application: PowerLauncher.exe
CoreCLR Version: 4.700.20.20201
.NET Core Version: 3.1.4
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for 'System.Windows.Threading.Dispatcher' threw an exception.
 ---> System.ComponentModel.Win32Exception (5): Access is denied.
   at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
   at System.Diagnostics.NtProcessManager.GetModules(Int32 processId, Boolean firstModuleOnly)
   at System.Diagnostics.Process.get_Modules()
   at System.Windows.WpfDllVerifier.VerifyWpfDllSet(String[] additionalDlls)
   at System.Windows.Threading.Dispatcher..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
   at System.Windows.Threading.DispatcherObject..ctor()
   at System.Windows.Application..ctor()
   at PowerLauncher.App..ctor() in C:\github\microsoft\PowerToys\src\modules\launcher\PowerLauncher\App.xaml.cs:line 33
   at PowerLauncher.App.Main() in C:\github\microsoft\PowerToys\src\modules\launcher\PowerLauncher\App.xaml.cs:line 44

First approch: start the application as suggested in this Raymond Chen's article
https://devblogs.microsoft.com/oldnewthing/20190425-00/?p=102443
It works for Win32 apps and for .Net Framework apps, it causes the crash when tested with the two .NET Core apps we have in PowerToys.

Second approach: use an intermediate process and drop the elevation in that process before starting the .NET Core app. It works when using SDDL_ML_MEDIUM but crashes when using SDDL_ML_MEDIUM_PLUS, in our scenario SDDL_ML_MEDIUM causes other issues so we can't use it.
https://github.com/microsoft/PowerToys/blob/e75a74565b8f7eb208af52dbb10632f943b66d21/src/common/common.cpp#L396-L421

Configuration

.NET Core 3.1.4
Windows 10 1909
x64

Regression?

Other information

I can provide a branch with the changes that cause the crash, if needed.

Tagging subscribers to this area: @eiriktsarpalis
Notify danmosemsft if you want to be subscribed.

[danmoseley]

The .NET Framework and .NET Core implementations of Process.get_Modules() seem the same -- ending up calling OpenProcess(Interop.Advapi32.ProcessOptions.PROCESS_QUERY_INFORMATION | Interop.Advapi32.ProcessOptions.PROCESS_VM_READ, inherit: false, processId);

I wonder if dotnet/coreclr#28019 is related? But that fix was present beginning in 3.1.3 (I verified) and the above is 3.1.4

@stephentoub anything occur to you?

[danmoseley]

@enricogior is it possible to try some other .NET Core versions? Specifically 3.1.2 or earlier. Any 5.0 preview might be an interesting datapoint as well.

[danmoseley]

Or perhaps @ericstj has a theory.

[jkotas]

The .NET Framework and .NET Core implementations of Process.get_Modules() seem the same

WpfDllVerifier that is calling Process.Modules is new in .NET Core.

It works for Win32 apps and for .Net Framework apps

Does it work for .Net Framework app that just calls foreach (ProcessModule procModule in Process.GetCurrentProcess().Modules) { Console.WriteLine(procModule); } ?

[jkotas]

The most likely explanation for this behavior is that the techniques to launch non-elevated process from elevated one strip the rights for the process to inspect itself. An experiment with an app that calls ProcessModule procModule in Process.GetCurrentProcess().Modules would confirm or deny it.

[danmoseley]

Thank you! I did not know that the Process.Modules call was new.

[enricogior]

@danmosemsft

is it possible to try some other .NET Core versions? Specifically 3.1.2 or earlier. Any 5.0 preview might be an interesting datapoint as well.

I tried 3.1.0 and got the same problem.
I wanted to try 5.0 but after installing the SDK, VS 2019 16.6 doesn't show it as available option:

C:\Users\enrico>dotnet --list-sdks
3.1.201 [C:\Program Files\dotnet\sdk]
3.1.300 [C:\Program Files\dotnet\sdk]
5.0.100-preview.4.20258.7 [C:\Program Files\dotnet\sdk]

Is there any other step required?

[enricogior]

@jkotas
when dropping the privileges using SDDL_ML_MEDIUM, the app starts without problems, but it doesn't have enough privileges for what we need. The crash happens when we use SDDL_ML_MEDIUM_PLUS that in theory should have higher privileges.

[danmoseley]

@enricogior can you please try the experiment @jkotas suggested above - create a.NET Framework console app and paste in Process.GetCurrentProcess().Modules;. Then try launching that with your launcher . We are guessing it will have the same issue.

[ericstj]

Agree with @jkotas assessment. In @oldnewthing's blog you see the technique you are using is copying permissions from some other process. You need to make sure the process you choose to copy has all the permissions that match an unelevated process. Likely Explorer doesn't have SeDebugPrivilege.

[enricogior]

@danmosemsft
I will test it with a .NET Framework.

@ericstj
still I don't understand why it doesn't crash when using SDDL_ML_MEDIUM, but it crashes when using SDDL_ML_MEDIUM_PLUS.