I suspect stack-scope of UserGestureIndicator could be the culprit but I don't know WebUI code enough to confirm or verify.
dpapad@: If the bug you fixed through the CL in #c1 is easy to repro, could you please verify if enabling our new model (chrome://flags/#user-activation-v2) makes the CL unnecessary?
Enabling chrome://flags/#user-activation-v2 seems to make the CL mentioned at #1 unnecessary. FWIW, here are the test steps.
1) Navigate to any extensions details page.
2) Find the "allow in incognito" toggle and drag it left/right.
Inspect DevTools console, there should be no errors (see attached
Comments 2-5: Thanks for checking that! mustaq@, do you know when chrome://flags/#user-activation-v2 will be enabled?
It would be great to make progress here, because this is important for issue 595841 (which we've wanted to fix for a long time).
Great to know UAv2 solves this and other related bugs!
We expect to ship UAv2 around M68. If our work around site isolation goes well, we plan to enable temporarily in M67beta.
#1: just to be clear, this bug isn't about the Blink side at all, so the stack-based nature of user gesture indicator today isn't a problem. This proposal is purely about a short-term workaround for tracking user gesture state on a per-WebContents basis. This would address some low-hanging fruit: certain WebUI pages have privileged operations that are supposed to be gated on user gesture, but this enforcement is purely renderer-side at the moment.
By tracking this on a per-WebContents basis, we'd be able to verify that the privileged methods requiring user gesture could plausibly have been triggered by one, rather than just being called by an exploited renderer with a fake user gesture on the stack.
IIUC, only a subset of privileged WebUI interactions with the browser process would be benefiting, right? Specifically user gesture checks could be added only for chrome.* private APIs (like developerPrivate, languagesPrivate) mutating methods.
Would it be possible to also add such checks within some mutating chrome.send() C++ handlers?
I'm curious, is this deliberately set as P1? This would add a reasonable but minor barrier for an attacker who has exploited an extension or otherwise gotten into a WebUI process (you have to induce a click by the user), but that level of exploitation should be difficult these days since extensions are now process-isolated from web content.
Owner: dcheng@chromium.org Status: Started (was: Available)
Given the number of times WebUI surfaces have been a component of sandbox escapes, I think P1 is appropriate. Granted, this is generally only the last step--but if we can break the last step, that would make exploitation even harder.
For now, the timeout delta is set at a fairly generous 5 seconds. Based on the Tabs.TimeSinceLastInteraction UMA measurement, we may tweak this downwards in the future.
(We may want to consider merging this to M-66 as well, if there's any chance of a respin)
This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Privilege escalation by opening an exe from chrome://downloads has been used as the final stage of many full chain exploits (two in the last month). We should break that last step.
Comment 1 by dpa...@chromium.org
, Mar 20 2018