Thanks for the report.  Can you produce a demonstration that doesn't require pasting a URL into the omnibox?  The same alert() can be generating with a pasted javascript:alert() URL.

This issue has some similarity to 571121 (where it is discussed in length). One of the other attack vector mentioned there is by using a malicious extension (with zero permission) that can open chrome-devtools:// URLs.

The main security issue is the ability to change Devtools' settings stored in localStorage by visiting the URL.

The maximum impact is demonstrated by execution privilege script (in Step#2) that gets access to filesystem (attached Devtools.Crafted-URL1.txt in orig report). If the inspected page is a regular webpage, it can read cookie-data etc. and send it to the attacker.

I repro'd the example on M51 stable.  Maybe these chrome-devtools:// links write to settings should require the referrer's scheme to be the same.

dgozman@ -- Can you find an appropriate owner?
Grabbing cc list from  http://crbug.com/571121 

PoC Video (Unlisted): https://drive.google.com/file/d/0BzBNDrWkH6nFcmNqWDU3czJTTTA/view?usp=sharing

dgozman: 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

FYI - One more Attack vector (besides malicious extension; copy-pasting URLs) is by sending a crafted chrome-devtools link via "Google Tone" extension. The extension allows sending URLs of any schemes to nearby machines.

dgozman: 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

Can't we just set a minimal CL for whatever appengine code is serving that?

That seems like a quick easy fix.

I don't think this is a problem. It requires user to 1) open url which cannot be linked to and 2) open DevTools for that page manually.

It's equivalent to opening DevTools for DevTools and executing any code in console, which anyone can do if they want.

Any thoughts from security experts?

The problem is that an extension with no permissions can navigate to that URL.

This is a variant of  bug 571121 , afaik the same discussion applies.

IIUC, this one requires the additional step of opening DevTools after navigation to the specific url (see step 2 in original report).

Ah, I missed that - that does make it very low severity!

But...it does seem prudent to have a way to prevent loading earlier revisions in case a bug does surface that is exploitable from just URL parameters (or with more realistic interaction)?

IMHO, at the very least, we wouldn't want a malicious extension overwriting DevTools' localStorage settings. For it to cause any sort of damage, the DevTools needs to opened to inspect a page at some point in time. 

Oh I see, so if at anypoint in future you open devtools, it still fires?

Well, that does seem bad?

The overwritten settings is persisted. You can set malicious watch-expression, or conditional (with malicious expression) breakpoints on various webpages, that can fire when devtools/sources-panel is opened to inspect that page. 

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

commit d5e6098dc2e984befc836f482845137245fa04e2
Author: dgozman <dgozman@chromium.org>
Date: Tue Jul 26 01:11:02 2016

[DevTools] Do not use "settings" query param.

Implemented the same functionality on embedder side.
Also, sanitizing "settings" query param for remote frontends.

BUG= 618037 

Review-Url: https://codereview.chromium.org/2177983004
Cr-Commit-Position: refs/heads/master@{#407666}

[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/chrome/browser/devtools/devtools_window.cc
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/chrome/browser/devtools/devtools_window.h
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/content/shell/browser/layout_test/blink_test_controller.cc
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/content/shell/browser/layout_test/layout_test_devtools_frontend.cc
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/content/shell/browser/layout_test/layout_test_devtools_frontend.h
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/content/shell/browser/shell_devtools_frontend.cc
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/content/shell/browser/shell_devtools_frontend.h
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/third_party/WebKit/Source/devtools/front_end/devtools.js
[modify] https://crrev.com/d5e6098dc2e984befc836f482845137245fa04e2/third_party/WebKit/Source/devtools/front_end/main/Main.js

I think we can merge the fix to M53 after it bakes in canary for a while.

Hi dgozman@ - this hasn't been in any of the queries for M53 consideration since it's not yet marked as fixed.  Are you expecting any more code changes?

I prefer to bake the fix in canary for a little longer. It's one of the non-obvious areas, where we'd better be more careful. We still have plenty of time for M53, and I don't want to merge this to M52.

Requesting to merge https://chromium.googlesource.com/chromium/src.git/+/d5e6098dc2e984befc836f482845137245fa04e2 to M53.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit 956afd761251b3e5897165a5ea5434e84f0882fb
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Mon Aug 08 17:13:39 2016

Merge to 2785 "[DevTools] Do not use "settings" query param."
> [DevTools] Do not use "settings" query param.
>
> Implemented the same functionality on embedder side.
> Also, sanitizing "settings" query param for remote frontends.
>
> BUG= 618037 
>
> Review-Url: https://codereview.chromium.org/2177983004
> Cr-Commit-Position: refs/heads/master@{#407666}
(cherry picked from commit d5e6098dc2e984befc836f482845137245fa04e2)
TBR=pfeldman

Review URL: https://codereview.chromium.org/2223093002 .

Cr-Commit-Position: refs/branch-heads/2785@{#529}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/chrome/browser/devtools/devtools_window.cc
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/chrome/browser/devtools/devtools_window.h
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/content/shell/browser/layout_test/blink_test_controller.cc
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/content/shell/browser/layout_test/layout_test_devtools_frontend.cc
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/content/shell/browser/layout_test/layout_test_devtools_frontend.h
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/content/shell/browser/shell_devtools_frontend.cc
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/content/shell/browser/shell_devtools_frontend.h
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/third_party/WebKit/Source/devtools/front_end/devtools.js
[modify] https://crrev.com/956afd761251b3e5897165a5ea5434e84f0882fb/third_party/WebKit/Source/devtools/front_end/main/Main.js

The panel has decided to award $1,000 for this bug, noting that it's more heavily mitigated than other related reports.  Many thanks as ever!

Thanks :)

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

Hi dgozman, your patch only filter the input from PC chrome, how to protect the mobile version?