Elevating WebView2 from non-admin account creates the msedgewebview2.exe processes as the non-admin user

[Coder666]

Description

When using "Runas" and elevating a WebView2 application from non-admin account, there is an issue whereby the msedgewebview2.exe processes are created as the non-admin user

This causes an access denied 0x80004005 error (presumably because the msedgewebview2.exe processes do not have permission to access the administrator application data)

Version
SDK: 1.0.705.50
Runtime: 88.0.705.68 (x64)
Framework: Win32
OS: Windows 10 20H2 Build 19042.804

Repro Steps

Login as a user who does not have administrative privileges

Run the application elevated as an adminstrative user by using "runas"

The application should then call CreateCoreWebView2EnvironmentWithOptions as below:

Set the userDataFolder to a directory within the users application data folder, for example the environment expansion of "%APPDATA%\MyApplication" i.e "C:\Users\Administrator\AppData\Local\MyApplication"

CreateCoreWebView2EnvironmentWithOptions(
NULL,
szAppData,
NULL,
Callback(this,
&CMyApp::OnWebView2EnvironmentCreated).Get());

The expected behaviour is that this would work fine and the application would be running on the desktop, with an elevated administrator token.

What actually happens is that the EnvironmentCompletedHandler produces an error code of 0x80004005.

Running process explorer you can see that some "msedgewebview2.exe" processes are started, and they are all running as the standard user rather than the administrator/elevated user. I believe that this is incorrect behaviour.

AB#31757028

[champnic]

Hey @Coder666, thanks for the bug report! Unfortunately WebView2 isn't well supported with the app running elevated at this time. You will notice some other issues like File Dialogs not being able to be created properly (#802). I've opened this bug on our backlog to take a closer look at this scenario. In the meantime, a workaround could be putting the user data folder into a location writeable by the logged-in user.

[champnic]

The browser/runtime processes run at Medium IL (as opposed to admin/High IL) by design, even when the app is elevated. We aren't looking to change that at this time. For your scenario, you'll want to make sure you choose a user data folder for which the runtime will have write permissions. Sorry for the inconvenience!

[romanan]

@champnic 2 questions about this:

1. For development, our build environment uses subst to map folders into a drive. The scripts that drive the build are elevated, so this results in the resulting subst'd drive being inaccessible to a non-elevated process. This is not an end-user problem, but a developer problem, is there any workaround we can use here?

2. For the end-user, will this prevent users from accessing on-disk HTML files that are inaccessible to non-elevated processes even if the user normally has access? Also for other locations that require permissions, such as network locations, etc. Our application does allow users to load their custom HTML.

[Coder666]

The browser/runtime processes run at Medium IL (as opposed to admin/High IL) by design, even when the app is elevated. We aren't looking to change that at this time. For your scenario, you'll want to make sure you choose a user data folder for which the runtime will have write permissions. Sorry for the inconvenience!

Apologies for the confusion, the issue is not with the processes running at a high IL.

The msedgeview.exe processes run under the incorrect user account because COM Cloaking/Proxy Blanketing does not appear to have been implemented in WebView2 (please correct me if I am wrong).

Further explantation:

Standard user: "test"
Admin user: "administrator"

Log in as "test" and attempt to elevate a webview2 application as the user "administrator". Note that the main application runs as "administrator" while the msedgeview2.exe applications run as "test".

The expected behaviour is that msedgeview2.exe would respect the CoInitializeSecurity settings of the main application and execute msedgeview2.exe as "administrator", the integrity level is completly irrelevant.

The point is that the webview runs under the wrong user account so cannot access the profile.

Is there already a way to use CoInitializeSecurity or a Proxy Blanket in order to run the sandboxed processes from the correct account?

[champnic]

Ah, sorry for the misunderstanding and thanks for the added info! I'll follow-up with the team on this bug.

[champnic]

@Coder666 I followed up with the team on this one and this is the response I got:
"COM security is not involved. We are not using COM to create medium IL msedgewebview2.exe process, nor is Chromium browser code all running inside a COM context that could impersonate the caller."

My understanding is that this would be very difficult or impossible for us to do, so I'm going to close this again. Apologies for the whiplash on this issue. The recommended workaround remains the same - to make sure the User Data Folder that is created/used has write permissions for the logged in user.

@romanan For 1) you would need to ensure that the subst drives are accessible by the logon user even if created while elevated, or otherwise ensure that it has write access. For 2) the WebView2 will generally follow the model of the browser, so if you see those files being accessible by the browser than WebView2 should be able to load them fine. I don't think it has as strict restrictions because generally it just need to read the HTML files rather than write to them.

[Coder666]

I have a question regarding Microsoft's suggested workaroud which I hope you can answer:

The workaround will allow a low privileged user read/write permissions to the webview2 data folder, while the main webview application runs elevated.

Could we get some clarification on the security risks of this?

Example scenario: The low privileged user modifies files in the data folder to causing untrusted javascript ICoreWebView2WebMessageReceivedEventArgs callbacks into the elevated C++ code

[romanan]

Another workaround option I've discovered is to use the Windows compatibility mode properties panel to set msedgewebview2.exe to "Run as administrator". This is probably only useful as a development tool or if WebView2 is deployed as a Fixed version.

[LiangTheDev]

@Coder666, WebView host app should not trust anything from the web content, whether running medium IL or high IL. The web content runs remote code and can't be trusted. As the message is received and processed in the app process, which IL we run the process to host the web contents doesn't matter.
We do run web content in sandboxed process with untrusted IL so that it could not cause too much damage if there is a bug allowing remote content to compromise the local process and run attacker's native code.
When a process runs high IL, if something got hacked, the damage is high. That's why we generally want to avoid running process as high IL.
FWIW, there are also some other security best practice as well, and they are documented at https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/security

[Coder666]

Thanks for your input. It seems that the workaround is in direct conflict with the security advice.

For anyone else experiencing this bug, we fixed the issue ourselves by moving our application to use the CEF library. Migrating to CEF only took two days, and now the process runs elevated as the correct user.