New issue
Advanced search Search tips
Starred by 5 users
Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment
Renderers won't start if Chrome is elevated on 10.0.10565
Project Member Reported by scottmg@chromium.org, Nov 4 2015 Back to list
After far too much confusion, I realized that as of Win10 10565, renderers fail to start if Chrome is "Run as Administrator".

This affects all of Stable to Canary.

(I normally run my main dev shell elevated which is how I noticed. I don't think we ever run Chrome elevated by default, but I'm sure this will affect some users.)

Renderers start if --no-sandbox.

The only time I can think of that we elevate is for system-install autoupdate, hopefully that doesn't conflict.


 
Comment 1 by wfh@chromium.org, Nov 4 2015
Cc: forshaw@chromium.org
Labels: Cr-Internals-Sandbox
So the problem is due to changes in impersonation in 10565. You can no longer assign an "elevated" impersonation token to a process with a non-elevated primary token. As we make the impersonation token using USER_RESTRICTED_SAME_ACCESS but use USER_LOCKDOWN for the primary this creates the mismatch and the impersonation token is downgraded to Identification only. What counts as an elevated token seems to be the presence of security critical privileges (such as SeDebugPrivilege) and certain SIDs such as Administrators group.

This should only affect systems with UAC enabled, if UAC is disabled completely (which is pretty rare to see, totally disabled is different from dropping the Control Panel slider to the bottom level) then it should work okay. If the user is running the disabled Administrator account (which is exempt from UAC, but from a system's perspective UAC is still on) then Chrome fails as well. This would probably only affect Server 2016 users as I doubt there are many people who intentionally enable the builtin admin account, but well crazy things have happened.

As for fixing we might want to wait until the fall update is final as things could very well change between now and then. This functionality was present in Windows 10 10240 but it wasn't on by default. Still we have a few options:

1) Change USER_RESTRICTED_SAME_ACCESS to USER_NON_ADMIN at least for Win10 fall release but perhaps for all cases where the browser is running as UAC admin, that removes the privileges and admin group SIDs. This would need to be done in both the GPU delegate and the main sandbox policy. The easier way of achieving this would have been to pass the LUA_TOKEN flag to CreateRestrictedToken always, but if you do that you can't disable the rest of the privileges for some reason.

2) If we're really running elevated then get hold of the linked token and use that instead. Unfortunately you need SeTcbPrivilege to get it via GetTokenInformation so you'd have to resort to opening an existing process on the desktop which is ugly. At any rate you'd have to use CreateProcessWithToken to create the new process as UAC admin doesn't have SeAssignPrimaryToken privilege and the normal user token doesn't meet the bar of token assignability.

3) We can use the same bait-and-switch trick we do with lowbox tokens, we create a process with an elevated primary token, set impersonation token (which satisfies the check), then switch the primary token out for the locked down one. I'd only consider this if no other technique worked or was deemed acceptable, such as we must impersonate as admin.

Worth noting that technically speaking the current operation of Chrome when run under UAC is a limited UAC bypass. As in if Malware was on the same machine and the user runs Chrome as Admin (obviously clicking yes to the prompt) then any new Chrome sandboxed process has for a time an impersonation token which is an Admin token just with a lower IL which a process running at medium should be able to access. This would at least be enough to read the majority of secured resources on the system and probably could be abused in certain system services to elevate privileges. So maybe option 1 should be used in all cases of UAC elevation?

I can take on developing a fix if we think it's worth covering this use case (and it does indeed break in final builds). 
Option #1 definitely seems cleanest, since it closes the UAC hole and I wouldn't anticipate anything breaking in warmup as a result. Can you think of any good reason to not just do it in all cases?
One thought I had was if any of the user's resources were created as the elevated user they would be owned by the the Administrators group. Depending on the resource and inheritance it might end up with a DACL which means the non-admin token can't access during warmup. To be honest if that happens I'd expect many things would start to fail, but still we'd need to keep track of weird crashes. That said I can't imagine there's many people who elevate Chrome, so it probably wouldn't cause major issues.

Also need to add a new level to the sandbox code as USER_NON_ADMIN doesn't add restricted SIDs, would need something like USER_NON_ADMIN_RESTRICTED. But that isn't a major concern I'd guess. I'll give it a test.
Yeah, my comment on warmup was in regards to accessing resources that are potentially restricted to the admin. I don't think that should be the case, because warmup is mostly accessing resources exposed to Everyone.

One other thought is whether USER_INTERACTIVE would be permissive enough to work for warmup, rather than adding a new level. Or maybe we should just make USER_INTERACTIVE permissive enough if needed, since we're not using it anywhere?
Status: WontFix
Doesn't seem to be happening on 10.0.10586.
It still might be something we want to fix for the potential UAC bypass, but would have to check with in TH2 to see exactly why it no longer breaks (perhaps again MS found back compat issues which rendered the security change impossible to enable by default). 
Owner: forshaw@chromium.org
Status: Assigned
OK, I'm out of my depth, so I'll let the rest of you decide if there's anything we should do here. :)
Comment 9 by jsc...@chromium.org, Nov 13 2015
Yeah, I still think we should fix the UAC hole, even if it is a very corner case usage. forshaw@ what did you think about just repurposing USER_INTERACTIVE?

Bigger picture, these token and job levels have gotten a bit non-sensical over the years. So, we may have reached the point where we need to sit down and rethink the interfaces a bit, to make them more consistent. But that would be a different bug, and would require at least a few cans of paint for the bike shed.
I put up a CL for testing out USER_INTERACTIVE. Generally it seems to work with no obvious problems but had issues with the win8 bot for some reason. Will try and investigate if it's just a weird flake or if the patch causes the issue. In the general case though I'd expect we can make this change.
Labels: Cr-Internals-PlatformIntegration
Labels: -Pri-1 Pri-3
Reducing priority as it's not an important issue to resolve.
Quick note on what changed with 10.0.10586. The impersonation function now checks a flag in the process token's logon session which is set if the session is the "limited" logon session in UAC. This means that the check doesn't fail if the process token is derived from the Full elevated token which fixes the issue without breaking the intended mitigation.

Also I can't seem to repro the Win8 bot failures to start the GPU process locally, it only fails on the bot itself. Wondering if the hassle of making it work is worth it.
Comment 14 by a...@chromium.org, Jan 4 2016
 Issue 573303  has been merged into this issue.
I can't seem to reproduce the merged issue with the exact same Windows 10 and Chrome Beta builds. I'm still trying to find a way to do this which works reliably across all versions of Windows and tests.
Comment 16 by car...@curig.net, Jan 4 2016
Windows version 10586.36 seems to have this issue (Chrome 48.0.2564.48 beta-m (64-bit)). Have worked around this with --no-sandbox in the meantime. Will test with a user not in local admins. I'd expect quite a few users that are savvy enough to be using the 64 bit version will also be in local admins (first user on install usually is).
Just so I can get a better understanding of why you're encountering the problem. Are you running Chrome elevated (e.g. you right click and select "Run As Administrator") or does it fail just running normally? What's UAC set to in the control panel, is is "Never Notify"? Was Canary affected (lost in the previous issue)? Stable?

If you can try it without a local admin that's something but it's possible that it's an unrelated issue as I cannot reproduce the behaviour personally with the same builds.
Comment 18 by wfh@chromium.org, Jan 4 2016
I can't repro on 10.0.10586 on 48.0.2564.48 beta-m (64-bit) using UAC elevation from a split token admin.

re: #16 can you export your local security policy [1], perhaps there is something in there breaking the sandbox?

[1] export both "Security Settings->Local Policies->User Rights Assignment" and "Security Settings->Local Policies->Security Options" using instructions e.g. https://teckadmin.wordpress.com/2013/08/09/import-and-export-windows-local-security-policy/
Comment 19 by car...@curig.net, Jan 4 2016
re #17 Started by just clicking the start menu item made by the installer. Completely uninstalled (no profile wipe) and reinstalled Chrome, same result. My user is in the local administrators group.

UAC is set to one down from top: "Notify me only when apps try to make changes to my computer" (default).

It may have something to do with one of these as this wasn't happening until yesterday although I may just have forgotten that I'd left --no-sandbox in my shortcut link:

Cumulative Update for Windows 10 Version 1511 for x64-based Systems (KB3116900)
Cumulative Update for Windows 10 Version 1511 for x64-based Systems (KB3124200)
Security Update for Internet Explorer Flash Player for Windows 10 Version 1511 for x64-based Systems (KB3132372)

I've just tried this with a brand new local user (non MS account) that's not in the administrators group and I get the same result with both the following:

Version 48.0.2564.48 beta-m (64-bit)
Version 49.0.2612.0 canary (64-bit)

Comment 20 by car...@curig.net, Jan 4 2016
re #18 Note that my windows version number Settings>System>About is showing 10586.36

FYI I got a popup upon starting secpol: "Namespace 'Microsoft.Policies.Sensors.WindowsLocationProvider' is already defined as the target namespace for another file in the store.

Attached exported security settings subtrees.

security-options.txt
8.1 KB View Download
user-rights.txt
2.7 KB View Download
Comment 21 Deleted
Comment 22 by car...@curig.net, Jan 4 2016
Note I do have Visual studio on this workstation, mentioning this as a tool and a possible culprit. Windows Update Insider Preview is also now showing me build 11082  as an available update. I'll hold off on this for now though.
Comment 23 by j...@stanford.edu, Jan 18 2016
I was seeing this issue with a stock standard install of Windows 10 on a Lenovo laptop, and was unable to use chrome after the Windows 10 stable update at the end of December. I finally dug into this today, and when I launched Chrome with the enable-logging flag, I saw the following output:

C:\Program Files (x86)\Google\Chrome\Application>chrome.exe --enable-logging                                                                                                                                                                    C:\Program Files (x86)\Google\Chrome\Application>[4560:9668:0118/071132:ERROR:cache_util_win.cc(20)] Unable to move the cache: 5                                                                                                                [4560:9668:0118/071132:ERROR:cache_util.cc(132)] Unable to move cache folder C:\Users\username\AppData\Local\Google\Chrome\User Data\ShaderCache\GPUCache to C:\Users\username\AppData\Local\Google\Chrome\User Data\ShaderCache\old_GPUCache_000     [4560:9668:0118/071132:ERROR:cache_creator.cc(127)] Unable to create cache                                              [4560:9668:0118/071132:ERROR:shader_disk_cache.cc(588)] Shader Cache Creation failed: -2    

Uninstalling without clearing UserData did not fix the problem, while uninstalling and clearing UserData did. 
Comment 24 by cpu@chromium.org, May 18 2016
Cc: cpu@chromium.org
Cc: -cpu@chromium.org -forshaw@chromium.org
Status: WontFix
I'm going to change this to WontFix as it's been a long time without it being a problem again. Also UAC split-token admin is not worth the effort securing against privilege escalation issues (for example see https://tyranidslair.blogspot.co.uk/2017/05/reading-your-way-around-uac-part-1.html and the 2, 3 parts). 
Sign in to add a comment