Resolve security questions around ZIP 321 and zcash: handler registration by malicious apps

[daira]

No description provided.

[daira]

See Electric-Coin-Company/zashi-ios#1093 and Electric-Coin-Company/zashi-ios#1094 .

[skyl]

User must willfully select the malicious app to handle the intent? Doesn't seem like a realistic or practical attack from my understanding.

[skyl]

Wallet-specific URIs wouldn't be useful or convenient. Seems like a bad idea.

[daira]

No, it's not correct that a user must willfully select the malicious app. Here's a write-up that covers that misperception.

Background on potential attacks

URI handler interception

It is not possible, on either Android or iOS, for a wallet app to reliably ensure that only it (or only other genuine wallet apps) can register as handlers for a given URI scheme.

On iOS, the behaviour is particularly unhelpful: one of the apps that registers for that scheme will be selected, but there is no user input, no reliable or documented specification of how the selection is made, and nothing in the UI that would indicate to the user that other apps are registered for that scheme.

On Android, the user is presented with a list of apps that have registered for the scheme, but there is no way to prevent a malicious app from having a confusingly similar name and icon to the correct app.

Activating the wrong app can have both privacy implications (the intercepting app gets the URI, and can potentially use the address, amount, etc. for social engineering attacks or in chain analysis), and integrity implications (the intercepting app could pass a modified URI, perhaps paying to the attacker's own address, to the real wallet app that has the user's spending keys).

Clipboard interception

The clipboard is not secure on either iOS or Android. Arbitrary apps can intercept and modify the clipboard contents, and there is no practical way to prevent this.

The visibility of this attack to the user depends on the platform version and the permissions granted to the malicious app. Modifying the clipboard contents (without reading them) never notifies the user on iOS or Android. There was also no visibility to the user of an app reading clipboard contents before Android 12 or iOS 14. After those versions, a system notification is supposed to be displayed (e.g. "${short app name} pasted from your clipboard" for Android). However, certain permissions allow this notification to be overdrawn on Android.

Proposed solution

It is safe to parse zcash: URIs from a wallet's own QR code scanner. We also propose to register a zcash: handler that only displays a message and then exits.

The message should convey to the user that they need to manually open the wallet they intend to use, and scan zcash: QR codes using that wallet's scanning UI. It would also be good to be able to allow the user to paste in a URI, but unfortunately we can't because of clipboard interception.

Hypothesis: this will be more convincing if the security problems are explained to the user.

Proposed wording of the warning screen

You have scanned or followed a zcash: link representing a payment request.

On $OS there is no way to ensure that this way of using zcash: links will reach your intended wallet app.

If a malicious app were installed on your device, it could:

• gain information about the payment, which could then be used in social engineering attacks or to link this use of Zcash with other transactions;
• modify the link and then pass it on to a real wallet app, which could result in you sending money to the wrong address.

These attack possibilities apply when scanning a QR code, following a link, or copying and pasting a link from the clipboard.

To maintain your privacy and security, please instead manually open the Zcash wallet app that you intend to pay with, and use its scanning feature to scan QR codes. If you do this in future then it will be faster as well as more secure: you won't need to go through this screen again, and you will be safer from any malicious apps.

For Zashi the scanner is [brief description of how to get to it].

We can't automatically open Zashi for you because this screen could also be faked by a malicious app. Thanks for reading, and sorry for the inconvenience.

         [Close this message]

[daira]

@LukasKorba and @true-jared raised the issue that according to iOS documentation and previous versions of Apple's Human Interface Guidelines (although I cannot find it in the current guidelines), an app should not quit programmatically. Instead it's intended that users tap the Home control to go back to the home screen (there is no equivalent of the Back control on Android).

It is definitely possible to adapt the behaviour to both follow the human interface guidelines and meet the security requirements. The warning screen tells the user to tap the Home button and go into the app again. The app detects the resulting UIApplication.willResignActiveNotification event and navigates to the app's main screen (while it is in the background), so that when it is foregrounded again it will be on the right screen. This teaches the user the safe way to act on a payment request QR code.

[nuttycom]

It is definitely possible to adapt the behaviour to both follow the human interface guidelines and meet the security requirements. The warning screen tells the user to tap the Home button and go into the app again. The app detects the resulting UIApplication.willResignActiveNotification event and navigates to the app's main screen. This teaches the user the safe way to act on a payment request QR code.

If the app instead just takes the user into the scanning UI in Zashi, how is that any worse? A malicious app that emulates this behavior can't gain any additional capabilities that it didn't already have. I think that the UX cost of what you're proposing here is too high for too little gain, vs. educating the user and then taking them to the camera to re-scan.

[daira]

That UI doesn't solve the "URI leaks information to malicious app" problem. You have to train the user not to use the system scanner for things that might be payment links in order to solve that. If they get directly to the place they need to be by doing the wrong thing, then they'll continue to do the wrong thing.

Don't think of just the specific case in which the link got intercepted, think of every future case with that user.