04 August 2020: Path derivation too permissive in Bitcoin derivative apps
05 August 2020: This security bulletin was updated to mention the publication of a new version of the Bitcoin app, add a disclosure timeline section, rephrase a sentence in the Remediation section and give a link to the patch.
Please read our support article if you aren’t interested in technical details.
Summary
The Ledger Nano S and Nano X are Hierarchical Deterministic (HD) wallets, meaning that they can derive different cryptographic secrets from a single seed. As written in the Threat Model, apps can derive keys on their own HD path only, which ensures that cryptocurrency apps cannot use keys from each other. For instance, the Zcoin app cannot derive keys on the Dogecoin derivation path (m/44'/3'/), since its own derivation path is m/44'/128'/.
This path restriction was not enforced for the Bitcoin app and most of its derivatives, allowing a Bitcoin derivative (eg. Litecoin) to derive public keys or sign Bitcoin transactions.
Technical Analysis
When installing an app on the Ledger Nano S/X, a list of allowed paths is provided. In the source code, it is usually specified in the Makefile of the app. For instance, the Monero app is allowed to use the path m/44'/128' (2147483692/2147483776) thanks to the --path parameter:
APP_LOAD_PARAMS= --path "2147483692/2147483776" --curve secp256k1 $(COMMON_LOAD_PARAMS) --appFlags 0x240
APPNAME = "Monero"
This parameter is enforced by the OS when any app retrieves a key used for public key derivation and transaction signature (using syscall os_perso_derive_node_bip32).
This parameter is however empty in the Bitcoin app and in its derivatives (at the exception of Qtum). The following table presents the coins affected by this lack of restriction:
| Coin | Affected (signature) | BIP 44 coin type | Forked coin |
|---|---|---|---|
| Bitcoin | Yes | 0 | / |
| Bitcoin Testnet | Yes | 1 | No |
| Bitcoin Cash | No (different signature format) | 145 | Yes (BTC) |
| Bitcoin Gold | No (different signature format) | 156 | Yes (BTC) |
| Litecoin | Yes | 2 | No |
| Dogecoin | Yes | 3 | No |
| Dash | Yes | 5 | No |
| ZCash | No (different signature format) | 133 | No |
| Horizen | No (different signature format) | 258 | No |
| Komodo | No (different signature format) | 141 | No |
| Stratis | Yes (against Peercoin family) | 105 | No |
| Peercoin | Yes (against Peercoin family) | 6 | No |
| Pivx | Yes | 119 | No |
| Viacoin | Yes | 14 | No |
| Vertcoin | Yes | 28 | No |
| Stealth | Yes | 125 | No |
| Digibyte | Yes | 20 | No |
| Qtum | No (lock already in place) | 2301 | No |
| Bitcoin Private | No (different signature format) | 183 | Yes (BTC) |
| Zcoin | Yes | 136 | No |
| Gamecredits | Yes (but to be removed) | - | No |
| ZClassic | Yes | 147 | No |
| XSN | Yes | 384 | No |
| NIX | Yes | 400 | No |
| Lbry | Yes | 140 | No |
| Resistance | Yes | 356 | No |
Enforcing the restriction to one or multiple paths for each coin type is actually a tough topic because:
- Some third party software wallets use incorrect derivation paths. This is a specific concern for older coins using third party wallets based on Electrum (Dogecoin, Litecoin, Dash, etc.)
- Some BTC forks use the same derivation path as BTC. If we prevent these forks from using the BTC derivation path, this would simply prevent users from using the Ledger Nano S/X with these forks.
For completeness, the following paths are standard for all Bitcoin variants:
- BIP 44 (
44'/type') - BIP 49 if supporting Segwit (
49'/type') - BIP 84 if supporting Native Segwit (
84'/type')
We can assume that by default all coins support those 3 paths for their type. Bitcoin being in use for some time, additional non standard paths have popped up:
- BIP 45 (
45'/type') for Copay multisignatures - “GA’/” (
18941'/) - GreenAddress proprietary for the shared multisignature address - Users can also sign on randomly selected paths with PSBT (Partially Signed Bitcoin Transaction from BIP 174)
Remediation
Blocking unusual paths from Bitcoin derivatives apps could fix the issue, but it leads to situations where user funds would be locked and users unable to spend their funds anymore. We thus chose to enforce a path lock in the Bitcoin app itself. If a Bitcoin derivative app tries to perform a derivation on an unusual path, a warning is displayed to the user.
In order to allow users to continue to use their Ledger Nano S/X seamlessly with any third party software wallet, this fix doesn’t enforce this verification from the OS though, which means that the --path parameter is still empty. We might add an exhaustive path list in the future if we are sure it doesn’t break any other wallets.
The vulnerability is fixed from version 1.4.6 of the Bitcoin app (being used as a library by the other apps) thanks to the commit 3f85053e.
Disclosure timeline
| Date | Action |
|---|---|
| 2020-05-02 | monokh sent to bounty@ledger.fr a vulnerability report about app isolation bypass. |
| 2020-05-04 | Ledger’s security team acknowledged the reception and starts investigating. |
| 2020-05-10 to 2020-05-13 | monokh and the Ledger security team discussed the issue. Ledger’s security team started coordinating other Ledger teams to fix it. A disclosure date is being set to 90 days (that is, 2020-08-02). |
| 2020-08-02 | 90 days deadline reached. Ledger started the test and release process for the fixed Bitcoin app. |
| 2020-08-04 | monokh published the details of the vulnerability, without informing Ledger’s security team beforehand through bounty@ledger.fr. |
| 2020-08-05 | Ledger updated the Bitcoin app. |
In this case, we regret not having respected the disclosure deadline, leading the security researcher to publish a blogpost on his website before a fix was made available for the users.
Besides other issues being handled at the same time, internal discussions to find an appropriate fix and coordination with other engineering teams took longer than expected. This led to a new version of the Bitcoin app being published after the scheduled deadline (that was set to 90 days after the vulnerability report).
Miscommunication didn’t help solving that issue sooner. The reporter sent Twitter DM messages that were missed by most of the security engineers. Indeed, the bounty@ledger.fr email address is the only way to reach the whole security team.
Credits
We would like to thank the security researcher monokh who reported the vulnerability through our bug bounty program.