New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775760 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Enable MojoJSTest bindings only in WebUI when under test

Project Member Reported by reillyg@chromium.org, Oct 18 2017

Issue description

Both the old GIN wrapper bindings for overriding Mojo interfaces in the renderer and new standard Blink bindings are currently enabled in all WebUI script contexts. This is necessary because the renderer is unaware of whether or not it is running inside of a browser_test and these bindings are needed by WebUI tests.

This issue tracks resolving this issue as it exposes an unnecessary and potentially exploitable API surface.
 

Comment 1 by creis@chromium.org, Oct 18 2017

Cc: nick@chromium.org dcheng@chromium.org tsepez@chromium.org nasko@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: -Pri-3 M-64 Security Restrict-View-SecurityTeam Pri-1
Thanks for filing!  I'm including a few Mojo security and Site Isolation folks and applying a few security labels out of caution.

For context, Nick and I raised a concern about this on https://chromium-review.googlesource.com/c/chromium/src/+/706380, and Reilly was already aware and had plans to improve this.

We should make sure to fix this in the short term if possible, because it sounds like test bindings are being given to highly privileged WebUI pages in practice.  These bindings are potentially quite risky (e.g., not reviewed with the same rigor and may be connected to untrusted or exploitable code on the other end of the pipe).
Just so that folks understand exactly what test bindings we are referring to, this issue refers specifically to the MojoJSTest bindings which is essentially just the MojoInterfaceInterceptor object. This object allows script running in a renderer to intercept Mojo interface requests made by the renderer when they would otherwise be handled by the browser process.

Comment 3 by creis@chromium.org, Oct 18 2017

Would that allow the WebUI process to be able to create its own services, similar to  issue 740710 ?  Given that some WebUI pages include web iframes today (which we're trying to fix), that would be concerning.

(I don't have enough Mojo knowledge to be sure-- just wanted to check.)
Adding rockot@.

This only allows the renderer to impersonate the browser process to itself.

Comment 5 by creis@chromium.org, Oct 18 2017

Thanks for confirming.  Doesn't sound too severe, though we should still clean it up to reduce the attack surface.  Thanks!
Status: Started (was: Assigned)
After assuming I would have to do something more complex I realized there was an embarrassingly simple solution to this problem.

https://chromium-review.googlesource.com/#/c/chromium/src/+/727477
Project Member

Comment 7 by bugdroid1@chromium.org, Oct 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8

commit 65cc6ac7e6299ecb0bc27e8224b75e186ce245c8
Author: Reilly Grant <reillyg@chromium.org>
Date: Thu Oct 19 04:05:34 2017

Enable MojoJSTest for WebUI only in WebUI browser tests

This change removes the additional "context enabled" feature for the
MojoJSTest bindings and instead simply modifies the base class for all
WebUI browser tests to add a command line flag enabling these bindings.

This enables the bindings in all renderers launched by such tests but
that is okay.

Bug:  775760 
Change-Id: I36ec28aed07ff9bcf46228f9828e157c96222723
Reviewed-on: https://chromium-review.googlesource.com/727477
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509994}
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/chrome/test/base/web_ui_browser_test.cc
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/chrome/test/base/web_ui_browser_test.h
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/bindings/templates/ConditionalFeaturesForCore.cpp.tmpl
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/bindings/tests/results/core/ConditionalFeaturesForCore.cpp
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/core/context_features/ContextFeatureSettings.h
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/core/exported/WebContextFeatures.cpp
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/core/mojo/test/MojoInterfaceInterceptor.idl
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/Source/core/mojo/test/MojoInterfaceRequestEvent.idl
[modify] https://crrev.com/65cc6ac7e6299ecb0bc27e8224b75e186ce245c8/third_party/WebKit/public/web/WebContextFeatures.h

Status: Fixed (was: Started)
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 19 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 10 by creis@chromium.org, Oct 19 2017

Hooray!  Thanks for the quick fix.
Project Member

Comment 11 by sheriffbot@chromium.org, Jan 27 2018

Labels: -Restrict-View-SecurityNotify allpublic
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