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
Owner:
Closed: Mar 20
Cc:
Components:
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 rebane2...@gmail.com, Mar 19

Issue description

VULNERABILITY DETAILS
This exploit abuses the history.replaceState JavaScript function to replace "From example.com" 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

VERSION
Chrome Version: 65.0.3325.162 + stable
Operating System: Windows 8.1

REPRODUCTION CASE
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
alert_exploit.html
272 bytes View Download
Cc: clamy@chromium.org
Components: Blink>WindowDialog
Labels: Security_Severity-High Security_Impact-Stable OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
Owner: a...@chromium.org
Status: Assigned (was: Unconfirmed)
Hmm, this is interesting. +avi and +clamy, can you take a first look at what's going on?
Labels: M-65
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
chrome_2018-03-20_07-16-54.png
23.6 KB View Download
2018-03-20_07-15-13.gif
76.0 KB View Download
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

Ignore my last post. Brain fail on my part.
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?
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"?
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 bugdroid1@chromium.org, Mar 20

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

commit 2ccbb407dccc976ae4bdbaa5ff2f777f4eb0723b
Author: Avi Drissman <avi@chromium.org>
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-on: https://chromium-review.googlesource.com/971661
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544518}
[modify] https://crrev.com/2ccbb407dccc976ae4bdbaa5ff2f777f4eb0723b/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/2ccbb407dccc976ae4bdbaa5ff2f777f4eb0723b/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/2ccbb407dccc976ae4bdbaa5ff2f777f4eb0723b/content/browser/web_contents/web_contents_impl.cc

Status: Fixed (was: Assigned)
Project Member

Comment 14 by sheriffbot@chromium.org, Mar 21

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.
*********************************
Cc: awhalley@chromium.org
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
Awesome!
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 sheriffbot@chromium.org, Jun 8

Labels: Merge-Request-68
Project Member

Comment 23 by sheriffbot@chromium.org, Jun 8

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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-68
Project Member

Comment 25 by sheriffbot@chromium.org, Jun 27

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