Issue metadata
Sign in to add a comment
|
Security: Address bar spoofing with interactivity |
||||||||||||||||||||||
Issue descriptionThis 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.
,
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).
,
Jul 6 2016
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!
,
Jul 6 2016
,
Jul 6 2016
,
Jul 6 2016
,
Jul 6 2016
,
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?
,
Jul 7 2016
> 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.)
,
Jul 7 2016
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.
,
Oct 14 2016
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 |
|||||||||||||||||||||||
Comment 1 by kenrb@chromium.org
, Jul 5 2016Owner: kenrb@chromium.org
Status: Assigned (was: Unconfirmed)