Issue metadata
Sign in to add a comment
|
Security: Navigation from http: to file: etc. is possible (Android)
Reported by
websec02...@gmail.com,
Apr 23 2017
|
|||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS <script> location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html'; </script> // content: location = 'googlechrome://navigate?url=content://com.android.chrome.FileProvider/downloads/a.html'; // view-source: location = 'googlechrome://navigate?url=view-source:https://www.google.com/'; Other schemes like android-app: and intent: may be used for the attack. Frankly, I'm not quite sure what the security impact of this bug is. What comes to my mind at this moment is the following two attack scenarios. 1) Non-HTML data theft Let's say http://target/json.php serves JSON content. -- http://target/json.php ------ HTTP/1.1 200 OK Content-Type: application/json; chraset=UTF-8 X-Content-Type-Options: nosniff {"secret":"1234", "attacker-controlled":"<script>...</script>"} -------------------------------- Here is an attacker's HTML. -- http://attacker/ ------------ <a id=a0 href="http://target-host/json.php/a.html" download>link</a> <script> // Download the target file. a0.click(); setTimeout(function() { // Navigate to the file with file: scheme. location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html'; }, 2000); </script> -------------------------------- Once downloaded, all the meta data such as Content-Type is lost, so the downloaded JSON can be treated as HTML/JS. In this attack, secret data in the JSON will be stolen. 2) Partial HTML data theft with CSS + UTF-16 In Chrome for Android v56 or earlier, the following attack works. + Attacker's page downloads both attack page (attack.html) and target page (target.html). + Navigate to file:///sdcard/Download/attack.html. + attack.html loads target.html as CSS with UTF-16 encoding. <link rel=stylesheet href=target.html charset=UTF-16> If the attacker controls the content of target.html partially, he can get the subsequent part of the content. You can find the details of CSS + UTF-16 attack at http://blog.innerht.ml/cross-origin-css-attacks-revisited-feat-utf-16/. My PoC is at http://ws9.me/ft8jtv/ (The page triggering the attack is attached). Attack 2 doesn't work on v57, where text/html contents are no longer downloaded to SD card. Note that both attacks rely on the Chrome's feature, allowing cross-origin content download. VERSION Chrome for Android 56.0.2924.87 stable on Android 6.0.0. 57.0.2987.132 stable on Android 7.1.1. REPRODUCTION CASE See the description.
,
Apr 25 2017
,
Apr 25 2017
,
Apr 25 2017
,
Apr 25 2017
location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html' I confirmed this works on 55.0.2883.84 on Android 6.0.0, too.
,
Apr 25 2017
Thank you for providing more feedback. Adding requester "meacer@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 25 2017
I tried on another device and was able to reproduce. This seems similar to bug 659489 . Tentatively assigning high severity. qinmin: Are you the right person for this bug? I'm not sure if it's an intents bug or a navigation bug.
,
Apr 25 2017
+some security folks
,
Apr 25 2017
To me, this looks like an issue with intent. The googlechrome:// scheme is really troublesome, a possible fix is to disallow using googlechrome:// to open a local page (either content or file URI), but i am not sure whether that is enough.
,
Apr 25 2017
,
Apr 25 2017
,
Apr 25 2017
I agree about restricting the googlechrome:// scheme. Do webpages ever need to be able to trigger it? It seems like only other apps on the device should be able to. I did check that this technique can't be used to navigate to chrome://-scheme privileged pages.
,
Apr 25 2017
a possible solution will be we check the app ID when IntentHandler.onNewIntent() is called, if it is from Chrome, we ignore it. However, this craetes some wierd UI issue that user click on a link with googlechrome:// scheme, intent chooser(chrome beta/dev/stable) comes up, and nothing happens if user chooses the Chrome version he is using.
,
Apr 25 2017
Rather than ignoring such an intent, we could just rewrite it to treat it as a normal renderer-initiated navigation.
,
Apr 25 2017
wierd, i cannot consistently repro the issue, the intent doesn't launch today, i was able to repro it yesterday on the same device.
,
Apr 25 2017
from the log, i saw "Navigation is blocked: googlechrome://navigate?url=file:///sdcard/Download/attack.html", source: file:///sdcard/1.html (0)", is there a finch experiment on frame loading? Or some recent change that already fixes the issue?
,
Apr 25 2017
qinmin: Do you see "Navigation blocked" message in logcat? That's what I saw when I had trouble reproducing.
,
Apr 25 2017
yes, see #16. I am using the same Chrome channel and didn't do any update between yesterday and today, so I am wondering whether this is caused by some finch configurations.
,
Apr 25 2017
I don't know that it will make a difference, but the PlzNavigate project is in a field trial on Canary and Dev. If you have c68ab9a3-6edc92c7 in your chrome://version, then you have it enabled.
,
Apr 26 2017
I am using stable, so it should be unrelated to PlzNavigate, and I couldn't find the the string in chrome://version
,
Apr 26 2017
Hmm. Do URLs below work? android-app://com.android.chrome/content/com.android.chrome.FileProvider/downloads/a.html intent:content://com.android.chrome.FileProvider/downloads/a.html#Intent;package=com.android.chrome;end intent:file:///sdcard/Download/a.html#Intent;SEL;package=com.android.chrome;action=android.intent.action.MAIN;end All these were confirmed to work with <script>location=... on both - 57.0.2987.132 stable android 7.1.1 - and 56.0.2924.87 stable android 6.0.0. If location doesn't work, <a href= or <script>window.open may possibly work...
,
Apr 26 2017
those URLs doesn't work for me either, I got the same "Navigation is blocked" error.
,
Apr 27 2017
"Navigation is blocked" reproduced on my device. It seems that, in the case of my PoC, we need to first visit http://ws9.me/ft8jtv/ then click the link to 1.html to make it work. When directly visit http://ws9.me/ft8jtv/1.html, it doesn't work. Transition type or something like that seems to be causing the difference.
,
Apr 27 2017
for #23, i saw the same behavior on M57. But when building from trunk, i saw both method won't work due to "Navigation is blocked". So someone patched the fix recently to all transition types.
,
Apr 27 2017
Nice, the bug was fixed then?
,
Apr 28 2017
I think so, mark this as fixed, please reopen if this is still reproducible on dev.
,
Apr 28 2017
It would be nice to find out which bug fixed this before closing. Can we bisect?
,
Apr 29 2017
Chrome dev (v59.0.3071.25 for Android) on my phones still allows navigation to intent:file:///sdcard/Download/a.html#Intent;SEL;package=com.chrome.dev;action=android.intent.action.MAIN;end android-app://com.chrome.dev/content/com.chrome.dev.FileProvider/downloads/a.html in <script>location= or <a href=. Tested on Android 6.0.0 and 7.1.1.
,
Apr 29 2017
,
May 1 2017
,
May 1 2017
I tried the same dev version, still blocked, need to look at why this is blocked when i got time
,
May 1 2017
,
May 2 2017
Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 2 2017
,
May 5 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 5 2017
I think I know why the navigation is blocked: In https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandler.java?type=cs&l=240, Chrome returns NO_OVERRIDE because the intent is heading towards Chrome itself. And then in https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/tab/InterceptNavigationDelegateImpl.java?type=cs&q=shouldIgnoreNavigation&l=137, since the intent is external protocol, and Chrome doesn't want to override the url, the navigation is thus blocked. However, I don't understand why the navigation works on some versions. Possibly someone is running a finch experiment that plays around navigation interception, and that bypasses the TabRedirectionHandler. Adding some folks could possibly know this.
,
May 5 2017
,
May 8 2017
Not aware of any experiments with TabRedirectHandler. However, this could perhaps be due to how the intent is set on the phones. We use intent.getPackage() (https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/tab/TabRedirectHandler.java?rcl=da7c77096c29ccd804917018dc74bebd925e164a&l=98) to figured out if the intent is heading to Chrome, so perhaps in some cases that's not set?
,
May 8 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 8 2017
For #38, i don't think think that is the case. I was able to repro the issue on my nexus 6P for a couple times, then the next day I was unable to repro it anymore. Since finch flags was not picked up on the first run, so my guess is that it is impacted by finch. Or could be a result of new Chrome version update which i didn't notice.
,
May 10 2017
,
May 22 2017
Removing merge approval label since it doesn't appear that any CLs need merging in M59. Please add back if I'm wrong.
,
May 25 2017
,
Jul 24 2017
,
Jul 25 2017
,
Aug 5 2017
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
,
Apr 25 2018
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by mea...@chromium.org
, Apr 25 2017