Issue metadata
Sign in to add a comment
|
Security: chrome://discards observed to share a process with an ordinary URL |
||||||||||||||||||||||
Issue description
VULNERABILITY DETAILS
In the attached screenshot, chrome://discards/ shares a process with an ordinary tab.
WebUI processes are supposed to be process-isolated from ordinary content. Specifically, chrome://discards/ has privileges to enumerate the loaded tabs across all profiles, and unload any tab in the tabstrip -- it seems to work by deleting the indicated WebContents and replacing it with a clone. chrome://discards can also navigate to other chrome:// URLs via window.open.
VERSION
61.0.3141.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 7
REPRODUCTION CASE
Currently unknown/vague. I've seen it happen twice today while experimenting with what happens at the --renderer-process-limit, and while discarding lots of tabs using chrome://discards. IBoth times were observed after returning to my machine after 15 or more minutes away. I may have used chrome://discards to discard another chrome://discards tab.
My full command line is:
"C:\Users\ncarter\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --disable-extensions --renderer-process-limit=3 --prerender=disabled --prerender-from-omnibox=disabled --flag-switches-begin --enable-features=AutomaticTabDiscarding --flag-switches-end
The following experiments were active:
AlternateComponentUrls:Control
AutofillFieldMetadata:Enabled
BackgroundVideoOptimizations:BackgroundOptimizationEnabled5sOrLessMediaSource
BrowserSideNavigation:Enabled_50
CheckerImaging:CheckerImaging2
ChromeChannelCanary:Enabled
ClientSideDetectionModel:Model3
DataCompressionProxyHoldback:Disabled
DefaultEnableGpuRasterization:Default
DynamicExpectCT:DynamicExpectCTEnabled
EnableMediaRemoting:Enabled_Dogfood
EnableSyncUSSDeviceInfo:Enabled
GpuScheduler:Enabled
GuestViewCrossProcessFrames:Control
Html5ByDefault:Enabled_Dogfood
InstanceID:Enabled
LazyParseCSS:Control
LoadingWithMojo:Enabled
NTPCaptureThumbnailOnLoadFinished:Enabled_Dogfood
NTPTilesInInstantService:Control
NetDelayableH2AndQuicRequests:Enabled2
OmniboxBundledExperimentV1:Dev_Desktop_NewAnswers_Dogfood
OmniboxEntitySuggestionDogfoodV1:Dev_Desktop_OmniboxEntitySuggestions_Dogfood
OmniboxTailSuggestionDogfoodV1:Dev_Desktop_OmniboxTailSuggestions_Dogfood
OneGoogleBarOnLocalNtp:Enabled_Dogfood
PageLoadMetricsMojofication:Control
PasswordGeneration:Enabled
PersistentHistograms:Default
PrefService:Control50_2
QUIC:EnabledAsyncSigning
SRTExperimentalEngineTrial:Control
SRTPromptFieldTrial:SRTCanary
SafeBrowsingThreatDomDetailsTagAttributes:Control
SafeBrowsingV4LocalDatabaseManagerEnabled:Control2
SettingsResetPrompt:Enabled_PromptDelay_120
SimpleCacheTrial:ExperimentYes
SlimmingPaintInvalidation:Default
SocketReadIfReady:Control
StabilityDebugging:Enabled5
SubresourceFilter:EnabledForPhishingSites_Dogfood
SyncUSSAutocomplete:Control
TriggeredResetFieldTrial:On
UKM:Disabled
UMA-Population-Restrict:dogfood
UMA-Uniformity-Trial-1-Percent:group_24
UMA-Uniformity-Trial-10-Percent:group_06
UMA-Uniformity-Trial-100-Percent:group_01
UMA-Uniformity-Trial-20-Percent:group_03
UMA-Uniformity-Trial-5-Percent:group_04
UMA-Uniformity-Trial-50-Percent:group_01
UseMojoAudioOutputStreamFactory:Enabled
V8AsmJsToWasm:AsmJsToWebAssembly
WebFontsInterventionV2:Enabled-2g-1
WebRTC-SimulcastScreenshare:Control_Dogfood
YieldBetweenContentScriptRuns:Enabled
,
Jun 26 2017
I've got a debugger attached to the instance now, and can work on getting a repro or classifying what might be going on.
,
Jun 26 2017
This seems serious. Does chrome://discards not use WebUI bindings? It probably should. Either way, it still seems like we should not be allowing it to share a process with web pages.
,
Jun 26 2017
,
Jun 26 2017
In the debugger, for the affected RenderProcessHost, I see three SiteInstanceImpl's in the RenderProcessHostImpl::observers_ list. The first has: site_ = "chrome://discards/" active_frame_count_ = 1 process_reuse_policy_ = PROCESS_PER_SITE The second has: site_ = "https://chromium.org/" active_frame_count_ = 4 process_reuse_policy_ = DEFAULT The third has: site_ = "https://google.com/" active_frame_count_ = 0 process_reuse_policy_ = DEFAULT The google.com one can be ignored, I believe -- looks like a history entry due to a navigation that occurred after the bad process placement had already occurred. In this steady state, any new tab I navigate to an ordinary website will join the chrome://discards process. What may be instructive here, is that the chrome://discards SiteInstance appears to be the first in this list: suggesting that a later https://chromium.org navigation joined an existing chrome://discards process, rather than the other way around.
,
Jun 26 2017
Digging into ChildProcessSecurityPolicy, it looks like the affected process's security state reflects has permissions to request the chrome scheme (granted by CommitNavigation), but not WebUI bindings. If I open chrome://discards/ in a new tab, it does seem to get bindings. If I clone (right-click, then 'clone tab') the affected 'chrome://discards/' tab, it hangs. However, if I navigate that hung tab again (focus URL bar, hit enter), it commits in the shared process. I am wondering if there's any relevance to alexmos's observations here: https://bugs.chromium.org/p/chromium/issues/detail?id=733767#c1 . However, there plznavigate fixes the problem, whereas it's enabled in my case.
,
Jun 26 2017
[Another question here is: how, exactly, does chrome://discards/ work, if the process isn't granted webui bindings?]
,
Jun 27 2017
,
Jun 27 2017
This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it. If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 27 2017
Please add appropriate OSs.
,
Jun 28 2017
I don't have reliable repro steps for the sharing just yet, but I am maybe halfway there -- here is a reliable way to set up two live WebUI processes (which is a violation of the PROCESS_PER_SITE reuse policy) for the same webui page: 1. open a new tab 2. navigate to http://www.chromium.org 3. navigate to a chrome:// URL (e.g. chrome://settings) 4. hit the back button 5. Ctrl+click the forward button 6. click the forward button You will wind up with two chrome://settings tabs in two different processes. I see this behavior on M61 canary, but not M58 stable.
,
Jun 28 2017
,
Jun 28 2017
Comment 11 may be a red herring. After further testing of these steps, it looks like what's seen there may just be a chrome TaskManager bug. These steps cause two TaskManager process groups to show up for the two tabs, but only if the TaskManager is made visible from step 1. If the TaskManager is closed and re-shown after step 6, you can see that the two tabs are in fact sharing a process.
,
Jun 29 2017
I split off the steps for Comment 11 into bug 738169
,
Jul 7 2017
,
Jul 11 2017
nick: tentatively assigning to you to remove from the sheriff queue since it looks like you have been investigating.
,
Jul 11 2017
A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.
,
Jul 14 2017
nick: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 26 2017
,
Jul 26 2017
URGENT - PTAL. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you! Know that this issue shouldn't block the release? Remove the ReleaseBlock-Stable label.
,
Jul 28 2017
nick: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 9 2017
Hi nick@ - what are your thoughts on next steps here? Cheers!
,
Aug 9 2017
[Bulk Edit] URGENT - PTAL. Your bug is labelled as M61 Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Know that this issue shouldn't block the release? Remove the ReleaseBlock-Stable label. Thank you.
,
Aug 15 2017
[Bulk Edit] URGENT - PTAL. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you! Know that this issue shouldn't block the release? Remove the ReleaseBlock-Stable label or move to M62.
,
Aug 15 2017
+awhalley@ (Security TPM)
,
Aug 17 2017
Removing owner to get this back into the sheriffing queue, as nick@ was the reporter and won't be the one who would ultimately fix. rsesek@, mind helping to route?
,
Aug 17 2017
,
Aug 17 2017
Alex: Could you take a look, based on what nick said in #6?
,
Aug 26 2017
We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue? For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 21 2017
Sorry that this slipped through the cracks. Nick, did you ever figure out the repro steps for this? I've tried to follow your leads with no success so far. Do you think we can try something like adding a DWOC at the point that we start sharing the process illegally? I'll reassign it back to you for now to follow up, since I'm about to go OOO. Regarding #6, I doubt this is related to that issue, as DevToolsUI is the only thing that ever modifies the default bindings (i.e., does SetBindings(0)), and discards appears to be using AboutUI.
,
Nov 3 2017
nick@, alexmos@ -- friendly ping from the security sheriff. please help triage this faster. thanks.
,
Nov 7 2017
We weren't able to find repro steps for this, and we suspect it may have been fixed by one of Alex's recent process reuse bug fixes, where pages were ending up in a process they shouldn't have been. I'll close this since we don't have evidence it's still possible, and we can reopen if that proves incorrect.
,
Feb 13 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mmoroz@chromium.org
, Jun 26 2017