Thanks for the report.

dgozman@, can you please take a look at this? I can verify that it repros on Stable. It looks like sanitizeRemoteFrontendUrl() should reject this so I'm not clear on how it works.

I don't think sanitizeRemoteFrontendUrl gets ever called; the query parameter accepts any value.

The only trick here was getting access to DevToolsHost by opening a new window, since it's not defined in the original one. An iframe would have worked too.

I suspect this was regressed by https://codereview.chromium.org/2620153002/.

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

Friendly ping from the security sheriff; any updates on this bug?

Also I'm wondering if this should be considered High severity instead of Medium. AFAIK DevTools is considered to be trusted like the browser process, so isn't an XSS in DevTools really a sandbox escape (albeit mitigated by the fact that you have to have DevTools open)?

Apologies for delay, looking into it now!

Fixed by this: https://chromium-review.googlesource.com/c/chromium/src/+/770511

> only expose bindings in window if opener has bindings or there's no opener

This seems insufficient. Here's a modified version of the original PoC where the final window has no opener:

chrome-devtools://devtools/remote/serve_rev/@199588/devtools.html?remoteFrontendUrl=javascript:w0=open();w0.w=open();w0.eval(`w.location="devtools.html";setTimeout(_=>w.eval(\`DevToolsAPI.streamWrite=(e,o)=>document.write(o);DevToolsAPI.sendMessageToEmbedder("loadNetworkResource",["file:///","",0]);\`),1000)`);top.location="data:,"

caseq: Given #9, can you please check if the fix is complete or if it needs more work? Thanks!

juhonurm: can you actually get it to work with the patch, provided that you disable additional safeguards in devtools_ui.cc? I couldn't, I think once the navigation happens due to w.location="devtools.html" the window is actually swapped and you end up with failed cross-origin check at w.eval(). At least that's what I see in DevTools attached to w0, and I didn't manage to get around that by tweaking your code so far.

palmer: I think we should be safe due to the fact that we're blocking fetch for chrome-devtools://remote/... with invalid URLs, which should be sufficient even without the check for opener in devtools_ui_bindings.cc, but of course I'd like to make sure that the said check is also effective.

caseq: I'll see if I can test that out later. I don't understand how you could get a cross-origin failure though, since w and w0 are both in the same origin the whole time and the code works in current stable just like original PoC. Nothing related to origins changed in the patch as far as I can tell?

You could try opening w0 explicitly in the devtools origin (as opposed to just about:blank) like this and see if it helps:

chrome-devtools://devtools/remote/serve_rev/@199588/devtools.html?remoteFrontendUrl=javascript:w0=open("devtools.html");setTimeout(_=>{w0.w=open();w0.eval(`w.location="devtools.html";setTimeout(_=>w.eval(\`DevToolsAPI.streamWrite=(e,o)=>document.write(o);DevToolsAPI.sendMessageToEmbedder("loadNetworkResource",["file:///","",0]);\`),1000)`);top.location="data:,"},1000)

I'm also not saying the patch itself is insufficient, my comment was aimed just at the opener part. Blocking the fetch should be enough on its own, but it seems to me the opener check doesn't really add anything other than unnecessary complexity.

juhonurm: so none of the snippets that rely on navigating a devtools window to devtools.html and later scripting it work for me, even on a version without my patch. The reason, I think, is that we're force-swapping the site instance upon navigation -- so yes, technically you have two windows with same origin, but they're in different processes and can't script each other.

I'm not entirely happy with just a loading-time check (i.e. one in devtools_ui.cc), because given our difficult history with problem like this one, it would be nice to have a check at the time of exposing bindings, just in case additional attack vectors emerge. For example, the loading-time check is not hit when the page is loaded from app-cache.

I'm closing the bug for now, since I think we addressed this particular problem, but if you come up with more ideas on how to circumvent either check, please feel free to re-open. Oh, and thanks a lot for these nice exploits!

HTML injection still possible; reported separately as issue 790695.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Hi juhonurm@, the VRP panel has decided to award $1000 for this bug, the amount reflecting that it's fairly heavily mitigated. Thanks for the new report, the panel will look at that in due course when it's fixed.

Also, how would you like to be credited in our release notes? 

awhalley: Thanks! Please credit me as Juho Nurminen.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

commit 484f731aaead5d72c26a21ea012cd2a706146f19 was initially in 64.0.3270.0, no merge needed.

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