Problem ------- A lightning node accepting a channel must check that the funding transaction output does indeed open the channel proposed. Otherwise an attacker can claim to open a channel but either not pay to the peer, or not pay the full amount. Once that transaction reaches the minimum depth, it can spend funds from the channel. The victim will only notice when it tries to close the channel and none of the commitment or mutual close transactions it has are valid.
Implementations did not always do this check: c-lightning: v0.7.1 and above do this correctly, prior versions never did. (CVE-2019-12998) - This can be exploited by a connecting peer and claiming to open a channel with any transaction id. lnd: v0.7.1 and above do this correctly, prior versions did not check the amount. v0.7.0 and above properly check for the scriptpubkey, v0.6.x partially enforces the funding scriptpubkey, but pre-v0.6.0 did not verify at all. (CVE-2019-12999) - Exploiting via incorrect amount is possible against all prior versions. In v0.7.0, the attacker must use the correct scriptpubkey, which burns the coins in the funding output. - Exploiting via incorrect scriptpubkey is possible on all versions prior to v0.6.0. This exploit is also possible in v0.6.x if the node is offline when the funding transaction reached the required number of confirmations and running with -txindex=0 on either full node backend. - Exploiting neutrino users (usually mobile or laptop) with an incorrect outpoint would require the attacker to collide their fake outpoint with the script of the real outpoint in the BIP 158 filter. The siphash key used to create the filters is derived from the blockhash. As a result, the attacker cannot directly grind outpoints without also knowing the block hash ahead of time. In addition, neutrino nodes are typically either non-listening or do not have an advertised address, which means an attacker would have to wait until receiving an inbound connection to perform either exploit. eclair: v0.3.1 and above do this correctly, prior versions did not if using the bitcoin core backend; electrum users only check the script, not the amount. (CVE-2019-13000) - Exploiting Electrum users (on mobile) requires the user to actively connect to a malicious Lightning node, and the attacker to use the correct scriptpubkey, which burns the coins in the funding output. Since Eclair Mobile doesn’t relay payments, the attacker can’t cash out without an offband interaction (e.g. selling something to the user and paying with the funds in the fake channel). Solution -------- Once the funding transaction is seen, peers MUST check that the outpoint as described in `funding_created`[1] is a funding transaction output[2] with the amount described in `open_channel`[3]. Background ---------- To open a channel, the funding peer sends `open_channel` with the proposed `funding_satoshis`. The fundee replies with `accept_channel` providing the keys it wants to use for the funding transaction. Then the funder creates the funding transaction, and sends the transaction id and output number in a `funding_created` message. ``` +-------+ +-------+ | |--(1)--- open_channel ----->| | | |<-(2)-- accept_channel -----| | | | | | | A |--(3)-- funding_created --->| B | | |<-(4)-- funding_signed -----| | | | | | | |--(5)--- funding_locked ---->| | | |<-(6)--- funding_locked -----| | +-------+ +-------+ - where node A is 'funder' and node B is 'fundee' ``` With this information, the fundee can create the signatures on the first "commitment transaction" and sends it in a `funding_signed` message so the funder can retrieve their funds should something go wrong. It is then safe for the funder to sign and broadcast the opening transaction. After some number of confirmations (set by the fundee), the channel is operational (`funding_locked`). The specification describes clearly the requirement to check that the various signatures exchanged indeed allow creation of a valid commitment transaction[4], and describes the requirement to wait for confirmations[5]. It did NOT, however, require the receiver to actually check that the transaction is the one promised by the funder: both the amount and the actual scriptpubkey. Discovery --------- Rusty Russell (Blockstream) discovered this while working on protocol tests for the specification itself, as part of an ongoing effort to test multiple new proposed features add new complexities.[6] The discovery occurred while writing tests for channel opening negotiation, in particular that invalid variants were rejected; while writing a test where the opener supplied an incorrect `funding_output_index` in the `funding_created` message, he realized that it would not be rejected by the c-lightning implementation, which only checked the confirmation count of the `funding_txid`, and not even whether the `funding_output_index` even existed! This requirement was not mentioned in the specification, so Rusty immediately disclosed the problem the authors of the other most widely used implementations (eclair and lnd). Their own investigations revealed that they were similarly vulnerable in limited circumstances. Together the teams made the decision to fix this quietly for pending releases, then reveal the existence of a problem 8 weeks later, once most users had already upgraded. Four weeks after that, the full disclosure would be made. While this long-standing bug had not been independently discovered, and thus was unlikely to be discovered by a malicious party before being fixed, it did provide an opportunity to test communications and methods of upgrade across the entire lightning ecosystem. Timeline -------- 2019-06-27: Bug discovered, LND and Eclair notified. 2019-06-28: CVEs assigned. 2019-07-02: lnd v0.7.0-beta released. 2019-07-03: Eclair 0.3.1 released. 2019-07-04: c-lightning 0.7.1 released. 2019-07-06: disclosure to other projects begins (rust-lightning, ptarmigan, BLW). 2019-07-30: lnd v0.7.1-beta released. 2019-08-17: [Review next dates based on deployment stats/problems] 2019-08-30: Reveal existence of CVEs, encourage laggards to upgrade. 2019-09-07: First conclusive evidence of exploit attempt in the wild. 2019-09-27: Full disclosure of CVEs. 2019-09-27: Submit PR to spec to require this. [1] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_created-message [2] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/03-transactions.md#funding-transaction-output [3] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-open_channel-message [4] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#requirements-2 [5] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_locked-message [6] https://github.com/ElementsProject/lightning-rfc-protocol-test _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev