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

Issue 625731 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security

Blocked on:
issue 497588



Sign in to add a comment

Security: Address bar spoofing with interactivity

Project Member Reported by mgiuca@chromium.org, Jul 5 2016

Issue description

This was reported in  Issue 497588  and also publicly here:
http://seclists.org/fulldisclosure/2015/Jun/108

However, two developments:
1. It was apparently fixed in M47. However I am still able to reproduce those POCs in Linux Chrome 53.0.2783.2.
2. I found this public post: http://sijmen.ruwhof.net/weblog/447-security-risk-analysis-of-address-bar-spoofing-bug-in-chrome-and-opera

Which claims to have gotten interactivity working on the spoofed page (the original POC is non-interactive only). See section "Solution for user input restriction". Possibly worth another look.

VULNERABILITY DETAILS
A malicious site is able to redirect to a trusted site while still controlling the rendered page content. Apparently, according to the second link above, the malicious site's content can be made interactive.

VERSION
Chrome Version: 53.0.2783.2 dev
Operating System: Linux
(my repro)

REPRODUCTION CASE
See above links.
 

Comment 1 by kenrb@chromium.org, Jul 5 2016

Cc: creis@chromium.org
Owner: kenrb@chromium.org
Status: Assigned (was: Unconfirmed)
I will investigate.

The linked blog post (which was written a year ago, before the CL for  bug 497588 ) does not claim interactivity with the spoofed page, though. Under the "User input not accepted" section the author talks about attempting to make the page interactive, and speculates incorrectly that it isn't responding because the SetTimeouts are keeping it too busy. In fact you could not interact with the page because the content has been unloaded from the renderer process. The PoC had only served to prevent the new page from successfully painting, which caused a mismatch between displayed URL and visible page content.

Comment 2 by kenrb@chromium.org, Jul 5 2016

mgiuca@: The PoC on the original bug doesn't repro for me on stable or trunk (testing on Linux).

Do you see a popup that has oracle.com in the URL bar but has "content.html" in bold on the page? For me the URL shows up but the page is blank (which is my CL working as intended).
Ah sorry, the POC I tried was this:
http://musalbas.github.io/address-spoofing-poc/

It is apparently a POC for the same issue. Clicking the link opens a popup that shows "This is not facebook.com. This is EVIL" and then redirects the URL bar to facebook.com. The "EVIL" text remains in the content area for some time (maybe 30s to a minute) while the URL bar reads facebook.com.

I wasn't able to try a POC of the interactivity one. If you don't think it's possible to reproduce that behaviour today, feel free to close this out. Thanks for looking!
Components: UI>Browser>Omnibox
Labels: Security_Severity-Medium Security_Impact-Stable
Status: Unconfirmed (was: Assigned)
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 6 2016

Labels: -Pri-2 Pri-1
Project Member

Comment 7 by sheriffbot@chromium.org, Jul 6 2016

Status: Assigned (was: Unconfirmed)

Comment 8 by kenrb@chromium.org, Jul 6 2016

#3: Regardless of interactivity, if the original behavior has regressed then this is a problem and I would certainly want to fix it. Unfortunately I still haven't been able to repro, even with the link you used. When I click on the link there I see the "EVIL" text for about 5 seconds and then it disappears to a blank page. I've tried Linux, Windows and Mac on stable (51), and trunk on Linux and Windows (which is M54 now).

Can you reproduce it on another machine or configuration? Are there any special flags you are running with?
> When I click on the link there I see the "EVIL" text for about 5 seconds and then it disappears to a blank page.

Yes, that's what I see too (it doesn't last particularly long). I suspect on a slower machine it would last longer (since this is based on a CPU DOS).

When you run the POC, do you see the facebook.com URL bar during those 5 seconds, or is it still the POC site's URL? (I see the POC site's URL for about 2 seconds, then facebook.com for about 3 seconds before the "EVIL" text disappears.)
Status: WontFix (was: Assigned)
Okay, thanks. This is working as intended then.

You briefly see the old site with the new URL, which is a time gap between when the new page has loaded and when it has finished rendering and painting. Those two events are usually very close together but the PoCs are constructed to deliberately delay rendering by hogging the main thread. My CL last year introduced a timer that clears the old content from the screen if a newly loaded page hasn't painted within a reasonable time. We don't want to do it immediately because it could cause flickers of white during normal navigation.
Project Member

Comment 11 by sheriffbot@chromium.org, Oct 14 2016

Labels: -Restrict-View-SecurityTeam 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