Looks pretty severe. I assume the user can interact with arbitrary content from the spoof page?

Not sure who to assign this to or where the bug is. Please adjust components as necessary and assign an owner.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks like a violation of the spoof defense in  issue 9682 , where the pending entry isn't supposed to be displayed once the initial empty document has been accessed.  I don't have time to look closely just yet, but I'll try to find time later today.

Hmm, I can't get this to repro.  The attached file in comment 0 causes a renderer crash in the original tab, and the navigation to www.yahoo.com succeeds.  I'm seeing this behavior on Windows 10 Canary 71.0.3548.0 (crash/aaf921f8805c5953), Windows Dev 70.0.3538.9 (crash/b1d74ad03ac10a1a), and Windows Stable 69.0.3497.81 (crash/dbc389802165dab7), as well as on Linux trunk.  That crash appears to be issue 825277, which dcheng@ might know more about.

Does this still repro on your side?  Any chance you could test it on Windows 10 to see if there's a difference there?

I'm still able to repro this on 71.0.3548.0 Canary on Windows 7 with using a new incognito window, unfortunately, I don't have Windows 10 on my machine. 

The cause of the crash was a print(). 

Deleted: poc (5) (1).html 380 bytes

poc (5) (1).html 380 bytes View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can also repero this with the test case in  issue 844881  which is fixed on Mac.

Deleted: poc (3).html 397 bytes

poc (3).html 397 bytes View Download

Thanks, but I still can't repro the spoof with the attached files in comments 9 and 12, in Windows Canary 71.0.3549.0.  In both cases, the navigation to the victim site (yahoo or amazon) succeeds, replacing the "spoof" page.  The address bar appears to say "about:blank" until the new page commits.

Could this be related to the difference in where Yahoo redirects?  In the video in comment 1 around 6 seconds in, the address bar changes from about:blank to https://maktoob.yahoo.com/?p=us&guccounter=1.  (For me, it redirects to https://www.yahoo.com/.)  The padlock is present at the moment it switches, which likely means that page has committed at that point (consistent with us not showing the URL until it commits).  The spinner proceeds a little longer, and then stops.

This seems more consistent with the new page not painting after commit, rather than a fully interactive spoof.  My hypothesis is that you can't interact with the "spoof" page after the new URL is visible.  Is that correct?  I'm surprised it doesn't blank out after 4 seconds from kenrb's timer, but maybe that gives us more of a lead if you can confirm that it's impossible to select text on the "spoof" page after the new URL is shown.

Let me know if there's anything else I might be missing in the repro steps.  So far the only difference I see is Windows 7 vs 10, so I can try to find a Windows 7 machine to test on if needed.

Can you also check if this repros for you on Chrome 69 or Chrome 70?  So far we only know it happens for you on M71.

This doesn't repro for me on Windows 7 either.

Maybe it has to do with how long it takes the victim site to respond, or to render?  I tried using http://build.chromium.org instead of http://www.yahoo.com and sometimes it shows up as a blank page, with build.chromium.org in the address bar.  (The "spoof" text gets cleared, though, so it's not a spoof.)  Other times the page loads succesfully.

It looks like the page's attempt to navigate to a 204 URL (http://www.google.com/csi) effectively cancels the next navigation, which the repro page does just after the next page commits.  I could see how that might interrupt a page load, though I'm not sure if that's intentional.  clamy@, do you know if navigating to a 204 should cancel an in-progress load or not?

Maybe we could get the results in the video if the 204 were timed such that the cancellation happens after commit and before the first paint?  If that's the case, I would definitely expect the spoof page not to be responsive to user input, and I would expect it to disappear after 4 seconds (unless there's an issue in kenrb's timer).  We might also be able to immediately clear the old paint if the committed navigation is canceled or otherwise stops.

All of this is still unconfirmed, though, until we can tell whether this outcome is possible based on a particular timing, and until we get confirmation on the questions in comment 13 (about responsiveness, which versions are affected, etc).  Assuming it's true, the difficulty in reproducing and the unresponsive spoof would drop this to Medium severity, I think.

Right, no more of repro on the latest version of canary 71.0.35450.0 on Windows 7. Thanks Charlie!

Ok.  If you do get it to repro at all (in case it's timing dependent, since I don't expect a that a fix landed for this), please let us know if the spoof text is interactive/selectable.  That would help us gauge the severity if it were made deterministic, and might help point to where the problem is.

Barring that, we might end up having to WontFix it if we don't find a way to repro it, but we appreciate the report either way.  Maybe there's a way to make it more reliable.

(I'll keep updating to Unconfirmed, since sheriffbot seems to have some rule that flips it.)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I haven't been able to make this repro, so I'll close this as WontFix.  Please do let us know if you're able to find a way to make it happen again, though.  Thanks!

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