a method to eliminate insecurity of intent for chrome on Android

[李佳佳]

Hi chromium-dev,

My team and I must say the feature is marvellous , which supports
chrome starting and jumping to application installed on the device via
a intent with scheme. Developers and Android users can make unique uri
via diy scheme in app , and the chrome can convert the uri to certain
intent , which can jump to linked application , such as deep link .
But we have been aware of the fact that the internal steps in chrome
handleing intent couldn't provide effective way to verify the app
where the intent towards is official or safe. Considering such case,
if a user downloads a fake app from the internet and installs it
instead of the official right one(they have the same package name), if
the intent for chrome jumps to the fake app, the app may be evil and
do somethings to harm the user's interests.In China, most Android
users can't access Google play service and store, so the chance they
install fake apps from internet
is very high.It can be dangerous feature in chrome on Android if the
bug is always unhandled.
I am glad to share you that we just did a small but significant work.
We modify some snippets in chrome source and add one process to verify
the signature of the app matches with the signature contained in the
intent. In fact, the intent can be formatable, and it should contain
the right
signature of the app it want to start. Then if the chrome finds that
the sha256 fingerprints from app and intent are not the same, it won't
handle the
intent any longer.
In our test, we turn the intent like
"intent://platformapi/startapp?appId=20000001&_t=1468848794586#Intent;scheme=alipays;package=com.eg.oandroid.AlipayGphone;end"
into
"intent://platformapi/startapp?appId=20000001&_t=1468848794586#Intent;scheme=alipays;finger256=38:9B:49:F7:83:2F:53:E9:01:79:23:22:0A:A8:5E:14:DF:AA:48:86:EC:D7:42:88:18:BF:33:95:43:CF:49:8A;package=com.eg.android.AlipayGphone;end".

As a result, chrome on Android can be more safe while it handle the
intent to some app installed.
The method is compatible for all chrome versions.

We have uploaded the patch and make a issue on codereview of chromium.

I hope you can think of my idea and help to review our code.
The url is https://codereview.chromium.org/2157933002/.

Best regards,

jiajia.li

[Rouslan Solomakhin]

+ChromeSecurity for their opinion.

 

I like this proposal. Thank you for coding it up. I can shepherd your patch through the code review process. Before you start making changes to the patch, let's get general agreement from the community that your design is correct. In particular, let's discuss a few minor details.

1. Would you be OK to rename finger256 into sha256? It's shorter and cannot be confused with the Unix "finger" command line utility.
   
   
2. Would you be OK remove the ":" characters from the signature or at least make them optional? That way developers can write "389B49F7" instead of "38:9B:49:F7".
   
   

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Rouslan Solomakhin]

Let's keep the rest of the mailing list on this conversation.

On Mon, Jul 18, 2016, 6:34 PM 李佳佳 <lijia...@gmail.com> wrote:

good idea! i  accept！i will fix it right now！

[Primiano Tucci]

I am not a security expert, but one thing that I find tricky in that approach is that it relies on keeping the web page and the apk signatures in sync. If I am reading the code correctly, in that proposal if an app wants to update the signatures for their APK (keys are expired, change of issuer, key revocation) they have atomically update all the links in the internet (very hard to imagine). And even if they manage to do that, users might be still lagging behind (e.g., auto update is disabled) and be in a situation where they have (new website with new signature)+(old apk with old signature).

So the only realistic plan for this to work across key rotations is that app developers should never remove signatures, just keep adding them. which is IMHO a tough requirement.

In other words, this feels to me the kind of feature that sounds very nice and appealing the first time you use it, and than turns out to be a footgun once you try to rotate keys of the apk. Essentially you are telling app developers: once you sign your app with a key X and you use X in the new intent scheme, you have to keep signing with X forever or some links will be broken.

I think one of the problems there is that the intent specifies *exactly one* key (fingerprint) to be matched against the set of keys of the apk.

Probably a better approach that could help dealing with key rotations in a sane way would be the if the intent could specify more than one key (with the any() semantic) to be matched against the apk signatures. But at this point this requires a discussion at the web platform level (intent to implement in blink-dev?)

Or maybe am I completely reading the proposal wrong?

The other thing that makes me a bit nervous about this, is that this would be a web-platform facing api that relies purely on an Android implementation detail to work. If at some point in the future Android will decide to lockdown getPackageInfo()* we (as a web platform) will be screwed.

* (I personally always found extremely disturbing the fact that any app can query for the existence of other apps without special permissions, but this is apparently "a thing" today)

[李佳佳]

Dear Primiano, 

I think your thought is ok. I am also hinking about it to solve the problem that two different signed apks have one same package name. Now I will modify the code to support multi key fingerprints in the intent and chrome, then if the app updates the key,  we can also support new and old sign key. 

I think app link in Android 6.0 also need to deal with the problem you described.

Regards,

Jiajia Li.

2016-07-19 21:05 GMT+08:00 Primiano Tucci <prim...@chromium.org>:

Hei Jiajia. 

To be clear, I find your proposal really interesting, I think there are some very good insights there.

I am just suggesting we should figure out the best and future proof way to materialize it, and think a bit more about future proof to get a good design.

You are right, though, that there are some extra constraints I didn't think about: you necessarily need to resign with the previous key to replace a package, although you don't have to necessarily change package name.

On Tue, Jul 19, 2016 at 1:55 PM, 李佳佳 <lijia...@gmail.com> wrote:

Thank you for your advice and attention so much.
But I don't think your concern is not as important as user's security. I will answer your question as list.
First of all, my proposal is kind like of app link feature introduced since Android 6.0, app link verifies the signature  from app and sha256 saved on website. And the cost of replacing the key in website is not expensive, referring to app link. But app link only supports https, now we extend to any other scheme.
(I think your question is also compatible for app link from google,---->https://developer.android.com/training/app-links/index.html😄 )

Secondly, consider your imagine that the app key is expired, it is a very good question, if you just update the key of app and keep the package name the same, user won't install new version app covering old one successfully. I think changing the package name may be a better way to solve this conflict. But anyway, no matter what happened, updating a key of app is very terrifying. 

Finally, if the key has been changed , and you insist concerning about the problem of syncing between app and website, I advise you can 
remove the param "sha256" in the intent scheme, which means backward to the original way of Android .
I am so glad to talk with you , I hope to communicate with you about it more.

Best wishes,
Jiajia Li.

[Christian Biesinger]

I'm not sure I understand the reason for this feature. The original email said this is to protect against malicious APKs *that are already installed*. Isn't that sort of the wrong level of protection? If you already installed a malicious APK, it can already do all kinds of bad things. What additional badness would clicking a link provide?

Thanks,

-Christian

[Torne (Richard Coles)]

On Tue, 19 Jul 2016 at 11:38 Primiano Tucci <prim...@chromium.org> wrote:

I am not a security expert, but one thing that I find tricky in that approach is that it relies on keeping the web page and the apk signatures in sync. If I am reading the code correctly, in that proposal if an app wants to update the signatures for their APK (keys are expired, change of issuer, key revocation) they have atomically update all the links in the internet (very hard to imagine). And even if they manage to do that, users might be still lagging behind (e.g., auto update is disabled) and be in a situation where they have (new website with new signature)+(old apk with old signature).

So the only realistic plan for this to work across key rotations is that app developers should never remove signatures, just keep adding them. which is IMHO a tough requirement.

Android signatures are verified by comparing *all* of the keys - it's an equality, not subset, relation. While you can sign APKs with more than one key, all that means is that updates must be signed with the exact same set of multiple keys. I don't think the key rotation support has been publicly documented yet and it only works on recent OS versions, but it doesn't work by adding additional signatures to the APK (it's more complex).

To match the behaviour of the platform, this would have to work the same way: a APK signed with multiple signatures should have to have *all* the signatures specified in the intent, I think?

[Torne (Richard Coles)]

On Tue, 19 Jul 2016 at 14:27 Christian Biesinger <cbies...@chromium.org> wrote:

I'm not sure I understand the reason for this feature. The original email said this is to protect against malicious APKs *that are already installed*. Isn't that sort of the wrong level of protection? If you already installed a malicious APK, it can already do all kinds of bad things. What additional badness would clicking a link provide?

It stops the app from receiving the intent parameters the website provided. It's conceivable this might include some private information/authentication/etc, though this seems like it's likely to be poor design in most cases?

[李佳佳]

If you speak like this, I don't think app link needs to verify the signature.  :) 

What I want to solve is to raise the accuracy of chrome notifying the fake evil app.

Suppose like this, sometimes a app for  paying is installed on the phone, the app is evil and fake,  it runs as normal . But when user shopping on chrome and comes to payment page , which may  jump to the app according to the intent, we can block the intent action at the time using sha256.

As your explantation, there is no need to install a antivirus app after the phone is infected by the virus app.😁

[Primiano Tucci]

> Android signatures are verified by comparing *all* of the keys - it's an equality, not subset, relation. 

Ah, TIL. Also I didn't think about the fact that today an app developer has already some similar problems of maintaining keys when pushing updates to the store. So, good point.

On Tue, 19 Jul 2016 at 14:27 Christian Biesinger <cbies...@chromium.org> wrote:

>I'm not sure I understand the reason for this feature.

Conversely to what happens in many other popular OSs, on Android apps are still quite isolated from each other (unless we are talking about a rooted phone, in which case you have lost beforehand and nothing in this discussion applies).

Depending on the permissions granted a malicious app on Android can do a lot of bad things (mostly privacy violations, e.g. send over the contact list, read messages, etc) but should not be able to compromise the integrity of other apps. This specific use case is a bit of a gray zone (read: Is this (Chrome) the best place where we should fix this?).

>It stops the app from receiving the intent parameters the website provided. It's conceivable this might include some private information/authentication/etc, though this seems like it's likely to be poor design in most cases?

I don't think this is necessarily about not leaking privacy information in the intent (yeah that smells really like a poor design). I think the realistic use case that lijiajiahyp@ is concerned about is: you are on an e-commerce website, you click on buy and you expect $your_legit_payment_system_app to show up. Instead $malicious_payment_app shows up, it looks identical but logs steals your CC numbers.

Again, I am not a security expert but the proposal sounds conceptually reasonable. It's more turning that into a practical and solid API which is the tricky part that worries me.

[李佳佳]

"To match the behaviour of the platform, this would have to work the same way: a APK signed with multiple signatures should have to have *all* the signatures specified in the intent, I think?"

Dear Torne,

I think you are right. One app can contain multi key signs. I will fix it.

[Torne (Richard Coles)]

On Tue, 19 Jul 2016 at 14:44 李佳佳 <lijia...@gmail.com> wrote:

If you speak like this, I don't think app link needs to verify the signature.  :) 

What I want to solve is to raise the accuracy of chrome notifying the fake evil app.

Suppose like this, sometimes a app for  paying is installed on the phone, the app is evil and fake,  it runs as normal . But when user shopping on chrome and comes to payment page , which may  jump to the app according to the intent, we can block the intent action at the time using sha256.

I don't think this will really do much to prevent this kind of attack. A malicious app on the device can already just pop its UI up over the top of a legitimate app any time it likes, even without seeing the intent.

Unless the intent itself is going to contain some data that shouldn't be shared with an untrusted app, I don't think it's that useful to enforce where it's delivered.

[Rouslan Solomakhin]

On Tue, Jul 19, 2016 at 6:26 AM Christian Biesinger <cbies...@chromium.org> wrote:

I'm not sure I understand the reason for this feature. The original email said this is to protect against malicious APKs *that are already installed*. Isn't that sort of the wrong level of protection? If you already installed a malicious APK, it can already do all kinds of bad things. What additional badness would clicking a link provide?

This protects the webpage from launching the malicious app. The author can better speak to the use case, but here's how I understand it. Currently AliPay integrates into Chinese websites by adding a [Pay with AliPay] button. When user clicks that on Android, the native AliPay payment app launches. The user must enter their username and password to proceed. Alibaba's concern is that the user might have installed a malicious clone of AliPay. Entering their AliPay username and password into a malicious app would be bad. The proposed feature should prevent it.

[Rouslan Solomakhin]

On Tue, Jul 19, 2016 at 7:41 AM Torne (Richard Coles) <to...@chromium.org> wrote:

Unless the intent itself is going to contain some data that shouldn't be shared with an untrusted app, I don't think it's that useful to enforce where it's delivered.

This question is for the AliPay engineers: Does the intent contain any sensitive data? I would imagine that merchant's identifier and total amount is in there. Is that right?

[Torne (Richard Coles)]

But it doesn't. *ANY* malicious app on the phone, even one with a completely different package name unrelated to AliPay, can notice that the AliPay activity has launched, and launch itself over the top with a phishing UI, already, without needing to communicate with Chrome at all. There's probably other similar ways to do this as well. In this case the user isn't safe even if they *have* got the real, signed version of AliPay.

It just doesn't seem like enforcing the intent here adds much real security.

[Rouslan Solomakhin]

On Tue, Jul 19, 2016 at 9:06 AM Torne (Richard Coles) <to...@chromium.org> wrote:

On Tue, 19 Jul 2016 at 16:33 Rouslan Solomakhin <rou...@chromium.org> wrote:

On Tue, Jul 19, 2016 at 6:26 AM Christian Biesinger <cbies...@chromium.org> wrote:

I'm not sure I understand the reason for this feature. The original email said this is to protect against malicious APKs *that are already installed*. Isn't that sort of the wrong level of protection? If you already installed a malicious APK, it can already do all kinds of bad things. What additional badness would clicking a link provide?

This protects the webpage from launching the malicious app. The author can better speak to the use case, but here's how I understand it. Currently AliPay integrates into Chinese websites by adding a [Pay with AliPay] button. When user clicks that on Android, the native AliPay payment app launches. The user must enter their username and password to proceed. Alibaba's concern is that the user might have installed a malicious clone of AliPay. Entering their AliPay username and password into a malicious app would be bad. The proposed feature should prevent it.

But it doesn't. *ANY* malicious app on the phone, even one with a completely different package name unrelated to AliPay, can notice that the AliPay activity has launched, and launch itself over the top with a phishing UI, already, without needing to communicate with Chrome at all. There's probably other similar ways to do this as well. In this case the user isn't safe even if they *have* got the real, signed version of AliPay.

It just doesn't seem like enforcing the intent here adds much real security.

What I'm hearing is that there're two problems in Android intents for the web:

1) There's no way to identify the callee securely.

2) Any app can detect launch of other apps and draw itself on top of other apps.

If that is true, then it is within out power to solve (1) today. So instead of two problems, we have only one remaining. The overall situation improves. If we solve problem (1) in Chrome today and Android solves problem (2) some day in the future, then our security will improve. Therefore, I'm in favor of adding this sha256 feature.

[Chris Palmer]

On Tue, Jul 19, 2016 at 3:31 PM, Rouslan Solomakhin <rou...@chromium.org> wrote:

But it doesn't. *ANY* malicious app on the phone, even one with a completely different package name unrelated to AliPay, can notice that the AliPay activity has launched, and launch itself over the top with a phishing UI, already, without needing to communicate with Chrome at all. There's probably other similar ways to do this as well. In this case the user isn't safe even if they *have* got the real, signed version of AliPay.

It just doesn't seem like enforcing the intent here adds much real security.

What I'm hearing is that there're two problems in Android intents for the web:

1) There's no way to identify the callee securely.

Well, you can send an Intent to a specific class (Intent.setClassName), which includes the package name, and Android enforces that only 1 package with a given name be installed at any 1 time. Of course, a malicious package can squat on the name of a good package, and if the device owner installs the malicious one first, well, too bad. But if the person managed to get the right package, then sending Intents to particular packages is decently safe.

I think there is some intent URI syntax to name the recipient package, but I can't remember what it is off the top of my head.

 

2) Any app can detect launch of other apps and draw itself on top of other apps.

This is true, and why I basically agree with Torne, even given the "well, package names seem maybe good enough" stuff I wrote above.

There is a notion of a SecureView, in which an input recipient can check for MotionEvent.FLAG_WINDOW_IS_OBSCURED and, if so, refuse to accept the event. (See https://github.com/appium/android-apidemos/blob/master/src/io/appium/android/apis/view/SecureView.java) One could imagine AliPay protecting its Views in such a way.

HOWEVER, that is not the problem here. EvilFakeAliPay is going to pop up, look completely good, accept the person's CC info, and win.

It's pure phishing, just like for passwords on the web. It's much more of a human problem than a software problem. One could imagine starting to solve it on Android with some kind of Uninterruptible Workflow concept, in which no other Activity can start until the web site's Intent to the One True AliPay App is delivered AND until One True AliPay App's Activity completes (Activity.onStop). But, there are a lot of reasons why that's difficult...

Given that, the approach to bad apps involves things like scanning the Play Store — or whatever other stores people in China use — for bad apps, and working to educate people that it matters whether or not they get the real AliPay, and where the real AliPay is available.

Yep, it's a bummer.

[PhistucK]

On Sat, Jul 23, 2016 at 5:43 AM, 'Chris Palmer' via Chromium-dev <chromi...@chromium.org> wrote:

Given that, the approach to bad apps involves things like scanning the Play Store — or whatever other stores people in China use — for bad apps, and working to educate people that it matters whether or not they get the real AliPay, and where the real AliPay is available.

​I do not think those applications are uploaded to the Play Store. Otherwise they would not have the same package name, right?​

☆PhistucK

[李佳佳]

Hi Torne，

The intent might contain some sensitive data, our feature could prevent those data from being hijacked by bad apps.

As for your suppose that malicious apps detect the action Alipay app launched by Chrome, I think this problem should be handled by Android system. Apps on Android run in secure sandbox mode, they need to ensure that application info is isolated and the operation info is private. As far as I know, the attack is hard to implement on an unroot Android device particularly on Android N.

What we concern is how to prevent bad apps from utilizing defects of mechanism to do bad things.

[李佳佳]

Hi Primiano,

Our proposal is to extend params based on #Intent mode at present, developers could use this params selectively in their scheme, aka the whole design is compatible. We are pursuing to implement it better and more effectively, but the method by adding selective params in scheme url , we consider it as the most convenient and effective way for the meantime.

 Well actually， I strongly suggest that put this feature (verifying callee app signature for intent) into standard intent mechanism, as well as service binding, it doesn't have to be used while chrome launching app.

 In China, some third-party payment company such as Alipay or Wechat usually develop payment sdk and serve it to some other merchants' app. Before the sdk in other app launches Alipay app or Wechat payment, sdk will verify Alipay or Wechat app's public Key

 is correct. Because os currently available can just accurate to package name or specific class in intent starting or service binding, but os can not ensure that the application installed are official. In many countries especially in China, almost all users would open the switch of "Unknown soureces" due to unreach google play service, and thus making os unable to ensure the security of the apps.

2016-07-19 18:38 GMT+08:00 Primiano Tucci <prim...@chromium.org>:

[李佳佳]

Hi Rouslan,

1.Intent itself supports conveying params, in China many apps would transfer sensitive data in intent, which developers in other countries might also do. When connecting to external merchants, Alipay carries information such as identifier and amount of money.(To protect these informtion from being stolen, the sdk Alipay sends to merchants would verify whether the local Alipay app is official or not, if not, the call for pay fails).

2、I totally agree with you :) .

[李佳佳]

Hi Chris，

1.You are definitely right on that point.That's also my motivation of coming up with the defense methods.

2.In China,  Google Play could't be acccessed directly, and there are no system-role stores to integrate the apps in the  third-party apps market. So all the cells of users are to be given an "Unknown Sources" option, it depends on the user where to download the app, e.g. from the webpage or from the QR code(very popular in China). The goverment and enterprises spare no effort to guide the pubilc to download the apps from the safe app-stores, but there are still a few people being cheated(The characters of Chinese are kind-hearted and simple ). Alipay is a company devoted to payment tech, so it's our job to provide the excellent service to our customers with respect. Now we want to make a difference in the market.  It would be a wise choice to cooperate with Google and submit this patch.

[李佳佳]

Hi PhistucK, 

In China,  Google Play could't be acccessed directly, and there are no system-role stores to integrate the apps in the  third-party apps market. So all the cells of users are to be given an "Unknown Sources" option, it depends on the user where to download the app, e.g. from the webpage or from the QR code(very popular in China). The goverment and enterprises spare no effort to guide the pubilc to download the apps from the safe app-stores, but there are still a few people being cheated(The characters of Chinese are kind-hearted and simple ). Alipay is a company devoted to payment tech, so it's our job to provide the excellent service to our customers with respect. Now we want to make a difference in the market.  It would be a wise choice to cooperate with Google and submit this patch.

[李佳佳]

Hi all ,

I have submitted the latest code for the new feature we discussed above at 

https://codereview.chromium.org/2167573003/.

This new feature is intended to ensure security while Chrome handling a custom scheme intent. It will verify the sha256 param carried by intent url , whether this value is as the same as sha256 value from application installed on the device. 

This new step can make sure Chrome launching official right application on the device. Aka we will prevent the intent from launching malicious phishing app, which can protect user from property being stolen or private sensitive data being collected at this very step.

We may not let the phishing apps disappear, but I think once we found weaknesses in practical security, we should

fix it and make this very weaknesses secure. As I said before, most Android users are kind and vulnerable by the internet, and this is not only in China, when we trying to education them to enjoy mobile internet securely, we also need to take some steps to protect them, particularly the old. 

Internet players may not think this feature can do big thing, in fact it may not , but as far as I know , many phishing apps have cheated users in this way. Phishing apps instead of official ones  installed on the device may do bad things again on the phone , but at least they are not launched by Chrome. So why not we do the little work to upgrade security while Chrome handling intent? 

We could work together to make it and I will be grateful for this.

Thanks.

Best regards,

Jiajia Li

[Rouslan Solomakhin]

Once again, I am in favor of approving this change. The code has some improvements before I am 100% happy with it, but it's moving in the right direction.

[Chris Palmer]

Unfortunately, I see new complexity but I don't see any new functionality or safety. I still agree with Torne: the underlying problem cannot be solved from the application layer, but must be addressed in the platform. Thus, I don't think we should accept this patch.

--
--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
 
http://groups.google.com/a/chromium.org/group/security

---
You received this message because you are subscribed to the Google Groups "security" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security+u...@chromium.org.

[Rachel Blum]

On Sun, Jul 24, 2016 at 3:57 AM, 李佳佳 <lijia...@gmail.com> wrote:

1.Intent itself supports conveying params, in China many apps would transfer sensitive data in intent

Intent delivery is fundamentally an insecure channel. Modifying Chrome to try to "glue on" security will not help - instead, you will need to deal with this like any other insecure channel. You will need to find a way to establish the recipient identity over an insecure channel, and then establish a secure channel.

I really don't think this is something Chrome should or even can do. 

[Joel]

Hi all. Popping in here as this has the look of being related to Subresource Integrity (SRI).

In short, I am in full agreement with Palmer, Rachel, and Torne. It appears that there's really only one protection this would give, which is over the content in the intent itself, but as Rachel points out, intents are fundamentally insecure and should not be trusted anyway, so it really would appear to just be encouraging an inappropriate use of intents.

That having been said, if we did decide to go with something like this, I'd strongly encourage us to rethinking this in terms of SRI, since it is an already existing mechanism for verifying resources, and v2 of the spec is very likely to cover downloads, which seems like a pretty similar use case.

--Joel

[Chris Palmer]

On Tue, Aug 2, 2016 at 3:59 PM, Joel <j...@chromium.org> wrote:

Hi all. Popping in here as this has the look of being related to Subresource Integrity (SRI).

I don't see a strong relationship. This is an attempt to ensure that the next Activity the person using the device sees, after Chrome, is the true AliPay app. It's "workflow integrity", if you will, and has nothing to do with ensuring the integrity of resources that a package depends on. (I called a hypothetical new platform feature to support this "Uninterruptible Workflow", earlier in the thread.)

 

In short, I am in full agreement with Palmer, Rachel, and Torne. It appears that there's really only one protection this would give, which is over the content in the intent itself,

Not as I understand it. I understand it as an attempt to ensure that the Intent goes only to the correct package. But you can already do that (Intent.setComponent, and see generally https://developer.android.com/reference/android/content/Intent.html). (Unless malware using your good application's package name got on the device first, in which case the device owner has other problems... and indeed, local malware of various flavors seems to be the patch author's primary concern. But as Torne described, the attacker has won in that scenario.)

[Rachel Blum]

On Tue, Aug 2, 2016 at 5:45 PM, 'Chris Palmer' via Chromium-dev <chromi...@chromium.org> wrote:

Unless malware using your good application's package name got on the device first, in which case the device owner has other problems...

I was only targeting the malware case w/ my comments, yes.

But as Torne described, the attacker has won in that scenario

More or less, yes. Either way, we seem to be pretty much in agreement that Chrome should _not_ attempt to establish the identity of the endpoint because it would establish a false sense of security.

[李佳佳]

Security of data transmission is just one aspect of our protection. We pay more attention to the request to jump from Chrome to a right app. I know Intent itself is an insecure channel deeply, but on the Android platform, we could assist with some other means to do data communication between different apps safely and conveniently, e.g. try target application signature authentication before binding a service or starting an activity(In China and other countries a large number of third-party SDKs contain such code), we often need to do such work to optimize the user experience. I think we should not explain to the victim developers with an reason that intent itself is for insecure channels, we should rethink about the problem from the vision of helping the developer.

    We can not expect any one program to solve all the problems, but we need to work towards a security direction, aimed to reduce the risk of user being cheated to the fullest.

    The current mechanism of Chrome launching other application, in fact, indirectly helps malware achieve realistic and more accurate phishing destruction (user clicks on a real button on a webpage in Chrome, but it launches a malicious app), and it is out of Android Security System itself. But in terms of this mechanism, the system can not solve it, because the launching process itself is legitimate.

We have been in pursuit of the ultimate security and experience, in current environment, it will make a malicious app develop cost very low without reasonable signature verification mechanism. A newcomer student may develop a malicious application in one day.

    And now Android introduces app links(https://developer.android.com/training/app-links/index.html), which also verifies the signatures of an app, I think app link is also aimed at security while Chrome launching the target app.

    In my opinion, we all should be more focused on: what can we do in the platform to raise malicious software costs, and what chould we do in Chrome to ensure protection of Chrome launching the app is offcail right to the fullest.

    In short, Android system is also working on upgrading the security of launching other apps, such as App Links, but it required http ssl, our patch is easier and better to put into practice. Current Android system launching app activity is not applicable to practice, it is still not secure, which can be easily utilized by hackers. We will never come to an end in security field. All the efforts are attempting to solve some specific problems. We have noticed that many cases users are cheated happen during Chrome launching wrong app, so we could try a purposed defense security method to reduce the cases.

[李佳佳]

Hi all, in fact out idea is inspired just by the assetlinks.json file in app-links feature introduced since Android M. It is more like a optional protocol. If we follow this feature, we can ensure that a user won't be cheated when he is shopping on Chrome and is about to launch payment app. That's what app links can do, but it requires https protocol. Our idea can support http. We think it is the advantage.

[Dapeng Liu]

Hi Joel,

A quick question: will SRI's new version cover intent?

Thanks,

Regards,

Max Liu

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Joel Weinberger]

On Thu, Aug 4, 2016 at 12:26 AM Dapeng Liu <maxpa...@gmail.com> wrote:

Hi Joel,

A quick question: will SRI's new version cover intent?

That's not in the plans, but I was suggesting that if we think this is an important use case, it might be good to think about it there. Palmer, however, disagrees, and thinks they are divergent enough concepts. FWIW, I still think they're related, and in fact SRI has considered anchor tags/links as a possible extension, but we never got too far with it.

[李佳佳]

Hi Palmer, Torne, and Rachel, 

I understand your points. But considering app links,  if the intent with fingerprint is not able to increase the security of launching other apps, I can not figure out their motivation of designing this. Can you help with my confusion ？

I will appreciate it so much.

[Dapeng Liu]

Hi Joel,

I personally think it is an important use case. 

The use case:

when the browser invoke native app using intent(and others) mechanism,   if the browser can verify the signature of the invoked application, it will prevent the user from invoking a malicious app. Although the malicious app may already exist before the browser's invoking, if the browser can detect that there is a malicious app the user is trying to invoke, it can alert the user. That will bring value to security.

Does that make sense?

Regards,

Max

[waxmiguel]

cheers!

>>>> Integrity <https://www.w3.org/TR/SRI/> (SRI).

--
waxmi...@gmail.com
waxm...@mail.ru
waxm...@bitrix24.com
0xC840F256B0F0FF9069E918d060063057AAaA6b36

[Dapeng Liu]

Hello all,

I would like to re-open this topic again with some additional thoughts:

1. Some background information: 

    Most Android users in China turn off the "verify App's signature " function. This leads to the problem of the fake/malicious App. 

One concrete example is that when a user trying to invoke Alipay from mobile browser, if the fake/malicious Alipay was invoked, the user may lose money. There are many victims and there is no effective way to solve this problem currently.  

2. Solution proposal:

 If Chromium can verify the signature of the native Apps it trying to invoke, it can at least alert the user (for example, by showing a full screen red page with a warning message that the browser is trying to invoke a fake/malicious App. Just as what Chromium does when trying to open an insecure https based website).

I agree with what Chris and others said that this can not solve all the problem, but it can indeed help the user to detect the fake/malicious Apps. This will avoid the user from losing money in the above case.  So this will bring value to security.

3. Does that make sense? 

If not, shall we discuss other alternative feasible solution to solve this problem in the list?

Thanks,

Regards,

Max Liu

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Dapeng Liu]

Hello all,

(Sorry if you see this mail multiple times. re-send in a new thread to facilitate the discussion..)

[Dapeng Liu]

[李佳佳]

Hi all,

Repo Dapeng's mail here, I hope we can discuss it again.

Really appreciate it if we can come to a conclusion.

Best regards.

[李佳佳]

Hi all,

Repo Dapeng's mail here, I hope we can discuss it again.

Really appreciate it if we can come to a conclusion.

Best regards.

---------- Forwarded message ----------
From: Dapeng Liu <maxpa...@gmail.com>
Date: 2016-08-17 15:51 GMT+08:00
Subject: Secure invoking Native Apps from Chromium
To: Chromium-dev <chromi...@chromium.org>, Chris Palmer <pal...@google.com>, "Torne (Richard Coles)" <to...@chromium.org>, Primiano Tucci <prim...@chromium.org>, 李佳佳 <lijia...@gmail.com>