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

Issue 841105 link

Starred by 6 users

Security: uXSS in Chrome on iOS

Reported by th...@inbox.com, May 9

Issue description

VULNERABILITY DETAILS
Universal XSS by using "..;@" within the url :~D

VERSION
Chrome Version: [66.0.3359.122] + [stable]
Operating System: [iOS]

REPRODUCTION CASE

Basically if we run this javascript code " history.replaceState('','','..;@www.google.com:%3443/') " from any domain using "HTTPS:" our URL domain is being replaced to that one..

For example: if this code is run on my site https://web-safety.net/ the the url is being replaced to https://www.google.com yet the contents remain under my control.. Therefore etc. we can run unrestricted XHR requests as long as the path is not absolute ('../myAccountInfo','../../SomeOtherSensitiveInformation')

Proof of Concept displaying Cookies in an iframe from https://www.google.com
https://web-safety.net/uxss_ios.html

This should work fine on any iOS on Chrome

Hope you like it! :~D

Cheers
Tom
 
Labels: OS-iOS
Summary: Security: uXSS in Chrome on iOS (was: Security: uXSS in Chrome on iOS :D)
Components: UI>Browser>Mobile Mobile>WebView>Glue
Labels: M-66 Security_Severity-High Security_Impact-Stable Pri-1
Owner: eugene...@chromium.org
eugenebut: Could you take a look at this?

I don't have an iOS device to test with, so leaving Unconfirmed but applying the labels as if it were for tracking.
Labels: -M-66 ReleaseBlock-Stable M-67
thomi@, is this bug reproducible in Safari or Firefox?
Cc: elawrence@chromium.org
This is a URL spoofing bug, where omnibox URL is incorrectly displayed. But I don't see XSS and "This are your cookies from 'www.google.com': don't print cookies.
Hey!
First.. Make sure you got some cookies already from www.google.com in the first place in case you are using incognito ;)
Secondly make sure you are accessing my PoC over HTTPS! Otherwise it will not work as the Origin does not mach HTTP..

Thirdly it's kind of weird.. if you do alert(document.domain) it will come back as: www.google.com says: web-safety.net
Yet we have access to cookies and we can do unrestricted XHR requests...

Do you want different types of examples of PoC?
Also this PoC only works on Chrome on iOS...
There are different ways to achieve that on other browsers on iOS or Safari on Mac but I think is irrelevant as this subject only focuses on Chrome.. Right?
It would be helpful if you could include screenshots of your reproduction.

(We are interested in understanding whether this reproduces in Safari and Firefox on iOS to better understand whether the root cause of the bug is in WebKit, or in WKWebView, or in Chrome code, which will help speed up the triage process).
Cc: pinkerton@chromium.org danyao@chromium.org
Status: Assigned (was: Unconfirmed)
Firefox crashes and I can reproduce this bug in stock WKWebView by executing very short JavaScript. rdar://40109702

Danyao, could you please take a look if this is something you or Ali can fix in WebKit? All the information is available with rdar://40109702.

Pink, could you please escalate this bug with Apple.

I will think if we can workaround the issue.
Here is a new Proof of Concept: https://web-safety.net/uxss_poc.html
Works on Chrome on iOS only...

Also I have attached screenshots what comes up on my screen.

Do you still want to me to create another PoC for Safari? Or you don't need it anymore?
01.jpg
123 KB View Download
02.jpg
666 KB View Download
03.jpg
701 KB View Download
04.jpg
435 KB View Download
Yes please create a PoC for Safari. It will help with our discussions with Apple. 
I escalated to our ADR team. 
Thank you Tomasz! It looks like some time is needed for XSS attack to steal cookie from iframe. As a workaround we could crash the browser once we detect the attack.

In your previous comment you mentioned that the vulnerability also allows to perform unrestricted XHR. Do you think it would be possible to execute XHR-based attack faster than iframe-based attack? Crashing the browser will limit the time available for the attack to succeed.
Cc: rohitrao@chromium.org
Developed a workaround to crash when URL change is detected. The crash will reduce the time available for this attack, which should either mitigate or make the attack impractical. The fix will be landed behind the finch flag: crrev.com/c/1054196
We briefly discussed in OH if this ever could happen for legitimate sites. What's the risk or likelihood of that?
Cc: mard...@chromium.org
+mardini as FYI
I believe it's unlikely that legitimate web sites would execute "history.replaceState('','','..;@another_domain/')" script. The crash will be launched behind the flag, so I guess we'll see if legitimate web sites crash.
So.. Here is PoC that should work on Safari on MacOS as well as on all other iOS based browsers (Safari, Firefox, Edge etc.) apart from Chrome iOS:
https://web-safety.net/uxss_poc_safari.html

I got a weird feeling that "history.replaceState" might not be the only way for this uXSS to work.. But I am not an expert ;)

Anyways.. Don't forget that this bug also allows for unrestricted open redirection on all domains as well.. Long story short, thanks to this I was able to find 4 XSS on *.google.com, yet guys said that those are not valid bugs as it's a browser bug in relation to open redirection..
Example: Some data URL is being controlled.. https://someService.googleapis.com/..;@custom_domain.com/

Let me know if I can help you in any way.. :)


Just to clarify comments #13 and #16. The workaround is to crash only if URL's password or username contains the origin of the previous URL. The crash is targeted specifically for this vulnerability and should not affect legitimate web sites. 
I guess this solution should do the trick..
Also XHR request takes a while too.. might be even longer than iframe + innerHTML to it.
Thanks Tomasz! I don't think Chrome can do better than crashing. The real fix should be done in WebKit.
Eugene, can you make sure the radar has the Safari info in it? That's our best avenue to getting apple to pay attention. 
Updated rdar://
Continuing the conversation from https://chromium-review.googlesource.com/c/chromium/src/+/1054196/2/ios/web/web_state/ui/crw_web_controller.mm#5199

If (_documentURL.GetOrigin() != newURL.GetOrigin()) inside URLDidChangeWithoutDocumentChange, isn't that *alone* enough to indicate that we're in an exploitable situation? Is there any scenario in which having a document's origin mismatch the URL's origin isn't a vulnerability?
|If (_documentURL.GetOrigin() != newURL.GetOrigin())| is more broad than the check in the CL. _documentURL detection in Chrome is not 100% reliable and using more broad check can lead to crashes during legitimate navigations (so yes, there are scenarios when _documentURL may be incorrect for a brief period of time). We working on refactoring navigation stack to improve _documentURL detection.


Cc: a...@apple.com ddkil...@apple.com
CC a couple of Apple security folks.

The bug is seems to be an error in URL parsing. Within WebKit, "https://web-safety.net/..;..;@mobile.twitter.com/robots.txt" is parsed correctly into the following parts:
- host: "web-safety.net"
- path: "/..;..;@mobile.twitter.com/robots.txt"
- user: ""
- password: ""

However, when this URL is sent to the network layer, the data returned is from https://mobile.twitter.com/robots.txt. So I suspect the error happens when the URL is serialized in the WebKit -> NetworkProcess IPC, and when reparsed, it is interpreted differently.

Maybe WebKit should escape ";" and "@" when processing replace state URLs. This seems to be what happens when "https://web-safety.net/..;..;@mobile.twitter.com/robots.txt" is entered directly into the address bar in iOS Safari.

Does anyone know what Blink does?

Tracking internally at Apple as: <rdar://problem/40258457>

Project Member

Comment 27 by bugdroid1@chromium.org, May 15

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

commit ba1815a412382038e41adc189134fcb1b75784aa
Author: Eugene But <eugenebut@google.com>
Date: Tue May 15 17:12:35 2018

Crash on unexpected URL change.

Bug:  841105 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I4471a98cdef13e54b790ebcd565d59c67dba8bfd
Reviewed-on: https://chromium-review.googlesource.com/1054196
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#558760}
[modify] https://crrev.com/ba1815a412382038e41adc189134fcb1b75784aa/ios/web/features.mm
[modify] https://crrev.com/ba1815a412382038e41adc189134fcb1b75784aa/ios/web/public/features.h
[modify] https://crrev.com/ba1815a412382038e41adc189134fcb1b75784aa/ios/web/web_state/ui/crw_web_controller.mm

Labels: Merge-Request-67
Status: Fixed (was: Assigned)
Project Member

Comment 29 by sheriffbot@chromium.org, May 15

Labels: -Merge-Request-67 Merge-Review-67 Hotlist-Merge-Review
This bug requires manual review: Less than 10 days to go before AppStore submit on M67
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Should we leave this open as ExternalDependency, since we probably want to remove the force-crashing when Apple fixes the bug for real? That, or file a new bug to track it.
Can we get unit tests please? Also how confident are you in this fix, Eugene?
Cc: kariahda@chromium.org
Status: ExternalDependency (was: Fixed)
Marking as ExternalDependency, because the code references this bug.

No, we can not write unit tests which verify that the app crashes. This is a risky fix which can introduce new crashes, but the change is behind the flag which can be turned off  on the server. Given the severity of this bug I believe we have to merge this to M67 per Security_Severity-High SLA.
Labels: -Hotlist-Merge-Review -Merge-Review-67 Merge-Approved-67
Approving per the high security severity and the fact that the change is behind a flag. Please merge asap.
Project Member

Comment 35 by bugdroid1@chromium.org, May 15

Labels: -merge-approved-67 merge-merged-3396
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/763ba59928da808a9b3f0da1ac777122f33507d3

commit 763ba59928da808a9b3f0da1ac777122f33507d3
Author: Eugene But <eugenebut@google.com>
Date: Tue May 15 20:44:48 2018

Crash on unexpected URL change.

TBR=eugenebut@google.com

(cherry picked from commit ba1815a412382038e41adc189134fcb1b75784aa)

Bug:  841105 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I4471a98cdef13e54b790ebcd565d59c67dba8bfd
Reviewed-on: https://chromium-review.googlesource.com/1054196
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#558760}
Reviewed-on: https://chromium-review.googlesource.com/1060377
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#609}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/763ba59928da808a9b3f0da1ac777122f33507d3/ios/web/features.mm
[modify] https://crrev.com/763ba59928da808a9b3f0da1ac777122f33507d3/ios/web/public/features.h
[modify] https://crrev.com/763ba59928da808a9b3f0da1ac777122f33507d3/ios/web/web_state/ui/crw_web_controller.mm

Cc: eugene...@chromium.org
Owner: ----
Project Member

Comment 37 by sheriffbot@chromium.org, May 16

Status: Fixed (was: ExternalDependency)
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -ReleaseBlock-Stable
Project Member

Comment 39 by sheriffbot@chromium.org, May 17

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Cc: srikanthg@chromium.org
Status: Verified (was: Fixed)
Verified in M67.0.3396.57 beta
iOS: 11.4 beta#6, 11.3.1, 11.2.6
Devices: iPhoneX, iPad Pro, iPhone8

App crashes as soon as the test URL from initial report is opened.
Labels: Release-0-M67
Labels: CVE-2018-6128 CVE_description-missing
Cc: linds...@chromium.org
Owner: eugene...@chromium.org
Cc: mpear...@chromium.org
Status: Assigned (was: Verified)
Re-opening this bug.  eugenebut@ can explain why.
The workaround had non-trivial amount of false positive crashes. We will disable the workaround in M67 with Finch kill switch until we deal we those crashes.
Labels: -reward-topanel reward-unpaid reward-7500
*** 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.
*********************************
Congratulations thomi@! The Chrome VRP panel decided to award $7,500 for this report.

Note that we usually only reward once the bug has been fixed, and this one just reopened, but in this case I'm going to process it now anyway.

 
Labels: -reward-unpaid reward-inprocess
Status: Verified (was: Assigned)
We fixed false positive crashes and shipped refresh build to AppStore. Finch kill switch was not used.
Project Member

Comment 54 by sheriffbot@chromium.org, Sep 12

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