Share Dialog
This Wednesday we are releasing the firmware update 1.9.1 for Trezor One and 2.3.1 for Trezor Model T devices. Apart from some internal refactoring tasks, the main reason to deliver the updates is to fix a security vulnerability found by Saleem Rashid. The bug was reported via our responsible disclosure program and we thank Saleem for yet another great contribution.
For non-Segwit transactions, Trezor always requires the previous transaction to check the UTXO’s real balance. Why? An attacker could claim that the UTXO’s balance is lower than it actually is. As you might know, the difference between input and output amounts is considered as the transaction fee in the Bitcoin network. That means the user would pay a significantly larger fee without actually knowing it. That is why Trezor requires the previous transaction to check the real amount.
This is true for non-Segwit transactions and this check was in place from the very beginning. With the introduction of Segwit, the Bitcoin developers tried to simplify this. When signing a Segwit transaction a slightly different piece of data is being signed. This is defined in BIP-143 and one of the changes was that the amount of the UTXO is present in the signed data. This helps significantly; if the attacker lies about the UTXO’s amount, the signature is simply not valid in the Bitcoin network.
Saleem found a clever way to circumvent this. Consider this scenario:
The victim has two SegWit/BIP-143 UTXOs of 15 BTC and 20 BTC.
The malware asks the user to confirm a transaction with input 1 as 15 BTC and input 2 as 5.00000001 BTC, with the user’s chosen outputs and a valid change output, if necessary.
The user confirms the transaction, spending 20 BTC plus 0.00000001 BTC fee.
The malware throws an error and tells the user to confirm the transaction again (e.g. “Uh, oh! Something went wrong. Please try again.”).
The malware asks the user to confirm a transaction with input 1 as 0.00000001 BTC and input 2 as 20 BTC, with exactly the same outputs as before.
The user sees an apparently identical transaction, and again confirms spending 20 BTC plus 0.00000001 BTC fee.
The malware uses the signature of input 1 from the first transaction, and the signature of input 2 from the second transaction, creating a transaction that in fact spends 15 BTC from input 1 and 20 BTC from input 2.
The user ends up paying a transaction fee of just over 15 BTC.
Note that this vulnerability is inherent in the design of BIP-143 and it is even hinted at in the Taproot proposal described in BIP-341 (Rationale, note 17). This flaw affects all hardware wallet vendors, some of which requested 90 days to implement the solution. That is why it took us longer than usual to release this fix because we respect the rules of coordinated disclosure.
The fix is straightforward — we need to deal with Segwit transactions in the very same manner as we do with non-Segwit transactions. That means we need to require and validate the previous transactions’ UTXO amounts. That is exactly what we are introducing in firmware versions 2.3.1 and 1.9.1.
Unfortunately, some third-party tools do not allow hardware wallets to obtain the previous transaction in case of SegWit inputs, which is why Trezor will not be able to sign transactions using these tools until they are updated to work correctly. Due to the responsible disclosure process, we were not able to inform the maintainers beforehand.
Applications using Trezor Connect version 8 will continue to work seamlessly.
If you encounter problems in your favorite Trezor-enabled web application, please let the developers know that they should upgrade to Connect v8.
We are providing a patch for Electrum as a pull request #6198. It will be impossible to use Electrum with Trezor 1.9.1 and 2.3.1 until this patch is released.
This section is of concern to users of HWI, BTCPay Server, and Wasabi wallet, as all these tools are internally using the BIP-174 PSBT format.
The PSBT format allows specifying either the full previous transaction or just the previous output. The latter is recommended for SegWit inputs. In order to fix the security issue, it is necessary to ignore this recommendation and supply full previous transactions in all cases.
A bug in HWI (issue #338) must be fixed to properly submit the previous transaction to Trezor. Afterwards, modifications to BTCPay Server (issue #1631) and Wasabi (issue #3734) will be necessary.
2020–03–03 — issue reported by Saleem Rashid, coordination with other vendors is required
2020–06–03 — firmware update 1.9.1 for Trezor One released
2020–06–03 — firmware update 2.3.1 for Trezor Model T released
Created by SatoshiLabs in 2014, the Trezor One is the original and most trusted hardware wallet in the world. It offers unmatched security for cryptocurrencies, password management, and serves as the second factor in Two-Factor Authentication. These features combine with an interface that is easy to use whether you are a security expert or a brand new user.
Trezor Model T is the next-generation hardware wallet, designed with the benefits of the original Trezor in mind, combined with a modern and intuitive interface for improved user experience and security. It features a touchscreen, faster processor, and advanced coin support, as well as all the features of the Trezor One.
Satoshi Labs
