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
Closed: Apr 2017
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, Apr 23 2017 Back to list

location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html';

// content:
location = 'googlechrome://navigate?url=content://';

// view-source:
location = 'googlechrome://navigate?url=view-source:';

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>
// Download the target file.;

setTimeout(function() {
  // Navigate to the file with file: scheme.
  location = 'googlechrome://navigate?url=file:///sdcard/Download/a.html';
}, 2000);

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
My PoC is at (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.

Chrome for Android
56.0.2924.87 stable on Android 6.0.0.
57.0.2987.132 stable on Android 7.1.1.

See the description.

1.1 KB View Download
Comment 1 by, 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, Apr 25 2017
Labels: Needs-Feedback
Comment 3 by, 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, 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, Apr 25 2017
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "" to the cc list and removing "Needs-Feedback" label.

For more details visit - Your friendly Sheriffbot
Comment 7 by, Apr 25 2017
Components: Mobile>Intents
Labels: Security_Severity-High Security_Impact-Stable OS-Android
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, Apr 25 2017
+some security folks
Comment 9 by, 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, Apr 25 2017
Labels: M-58
Project Member Comment 11 by, 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, 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, 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?


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> 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 then click the link to 1.html to make it work.
When directly visit, 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


in <script>location= or <a href=.

Tested on Android 6.0.0 and 7.1.1.

Project Member Comment 29 by, Apr 29 2017
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member Comment 30 by, 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, 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 - Your friendly Sheriffbot
Labels: -M-58 M-59
Project Member Comment 35 by, 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 - Your friendly Sheriffbot
I think I know why the navigation is blocked:

In, Chrome returns NO_OVERRIDE because the intent is heading towards Chrome itself.

And then in, 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.
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() ( to figured out if the intent is heading to Chrome, so perhaps in some cases that's not set?
Project Member Comment 39 by, 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 - 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, 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 - Your friendly Sheriffbot
Sign in to add a comment