New issue
Advanced search Search tips

Issue 823353 link

Starred by 2 users

Issue metadata

Status: Fixed
Closed: Mar 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security

Sign in to add a comment

Security: Show javascript alert on a site by clicking on a link from that site

Reported by, Mar 19 2018

Issue description

This exploit abuses the history.replaceState JavaScript function to replace "From" with "From this page" in javascript alert titles, while appearing to come from a page the link to this exploit was clicked from, after which, it will open a new page with a blank url and content of attacker's choice
This could very easily be used for social engineering

If required, I can attach a screenrecording of a potential attack scenario

Chrome Version: 65.0.3325.162 + stable
Operating System: Windows 8.1

1. Upload the included html file to the attacker's server
2. Add a link to the html file on a trusted website
3. Click on the link
4. A javascript alert box will show up, seemingly coming from the trusted website, with a title that says "From this page"
5. After clicking OK on the message, a website of attacker's choice appears, with the url set as "about:blank"
I uploaded the wrong version of the exploit, please use this one instead
272 bytes View Download
Components: Blink>WindowDialog
Labels: Security_Severity-High Security_Impact-Stable OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
Status: Assigned (was: Unconfirmed)
Hmm, this is interesting. +avi and +clamy, can you take a first look at what's going on?

Comment 3 by, Mar 19 2018

Labels: M-65

Comment 4 by, Mar 19 2018

Can you attach a picture of the time when the dialog is up, what the effect you've created looks like?
I've attached a screenshot and a short gif of it in action
23.6 KB View Download
76.0 KB View Download

Comment 6 by, Mar 20 2018

I find it even more troublesome without replaceState, as then the URL that the dialog is attributed to is the old one, not the new one.

Comment 7 Deleted

Comment 8 by, Mar 20 2018

Ignore my last post. Brain fail on my part.

Comment 9 by, Mar 20 2018

OK. replaceState is used to switch out the URL to something not parseable, so the JS dialogs switch to "this page". Meanwhile, since the dialog is the first thing the page does, it locks up the render process so that it can't provide rendering, and thus the view of the old page remains.

Even if we can't show the new page, how can we at least force the old page to stop showing?

Comment 10 by, Mar 20 2018

What happens here is that RenderWidgetHostImpl has a TimeoutMonitor named new_content_rendering_timeout_. When a page is committed, in RenderWidgetHostImpl::DidNavigate() the timer starts. If it fires (after kNewContentRenderingDelayMs, or 4s) then the widget realizes that something is wrong and blanks the page.

The problem is that the render process is blocked with the dialog, and there *won't* be a new paint, and the browser *knows* this. Can we make a call on the widget to say "hey, if there's currently a paint timer, expire it immediately"?

Comment 11 by, Mar 20 2018

Labels: -Security_Severity-High Security_Severity-Medium
It sounds like the omnibox shows the correct URL for the 'this page' being referred to by the dialog, and there is only 4 seconds of this spoofing behavior. I'm downgrading the severity accordingly.
Project Member

Comment 12 by, Mar 20 2018

The following revision refers to this bug:

commit 2ccbb407dccc976ae4bdbaa5ff2f777f4eb0723b
Author: Avi Drissman <>
Date: Tue Mar 20 21:11:36 2018

Force a flush of drawing to the widget when a dialog is shown.

BUG= 823353 
TEST=as in bug

Change-Id: I5da777068fc29c5638ef02d50e59d5d7b2729260
Reviewed-by: Ken Buchanan <>
Commit-Queue: Avi Drissman <>
Cr-Commit-Position: refs/heads/master@{#544518}

Comment 13 by, Mar 20 2018

Status: Fixed (was: Assigned)
Project Member

Comment 14 by, Mar 21 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-1000
*** 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.
Thanks for the report! The VRP panel decided to award $1,000 for this report. A member of our finance team will be in touch to arrange for payment.

Also, how would you like to be credited in release notes?
Labels: -reward-unpaid reward-inprocess
I'd like to be credited by my full name, Jasper Rebane
Labels: -M-65 Release-0-M67 M-67
Labels: CVE-2018-6135 CVE_description-missing
Project Member

Comment 22 by, Jun 8 2018

Labels: Merge-Request-68
Project Member

Comment 23 by, Jun 8 2018

Labels: -Merge-Request-68 Hotlist-Merge-Review Merge-Review-68
This bug requires manual review: M68 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), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit - Your friendly Sheriffbot
Labels: -Merge-Review-68
Project Member

Comment 25 by, Jun 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 - Your friendly Sheriffbot
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment