Author: Antoine Riard 2020-10-20 22:05:12
Published on: 2020-10-20T22:05:12+00:00
A vulnerability has been discovered in Lightning Network nodes that could allow an attacker to steal in-flight HTLCs. The vulnerability involves the use of high-S (above curve order/2) signatures, which are not tx-relay standard and won't be relayed/mined on the regular p2p network, but are still consensus-valid. An attacker can provoke a permanent tx-relay failure of victim transactions and steal in-flight HTLCs once they expire as the victim can't trustlessly claim them on-chain during the CLTV delay. The LND team has adopted a solution that normalizes any high-S signature provided by the counterparty to a tx-relay standard one.Lightning node security relies on being able to unilaterally broadcast channel transactions to enforce an off-chain negotiated balance. Channel transactions are asymmetric, and each party owns a different version including all parties' balances/HTLCs. Signatures for commitment transactions and HTLCs are provided at channels updated by a counterparty's `commitment signed`. Once it's accepted, the local node must release the revocation secret for the previous channel state and rely on the validity of highest state transactions for its funds' safety. The vulnerability is a case of transaction standardness malleability, and transaction standardness is a set of supplementary anti-DoS rules on top of Bitcoin consensus rules. This set of rules isn't well-defined, and there is no _a_ tx-relay policy, but many tx-relay policies depending on full-node policy, which varies across implementations and versions. This situation is concerning and sounds to have been an undersight during Lightning/payment channels protocols design. The tx-relay standardness issue has a wider effect as other time-sensitive multi-party protocols like vaults/CoinSwaps are affected. All Bitcoin software implementing this class of protocols must correctly sanitize counterparty contribution to avoid jeopardizing funds security or introducing easy DoS.The LND team fixed the vulnerability and released lnd v0.10.0-beta, followed by v0.11.0-beta. The CVE-2020-26895 has been assigned to this vulnerability. After the expiration of a preimage with an outdated utility, there has been a vulnerability in the channel timelocks which could have been exploited. The attack building block may differ from a malicious mempool-congestion but the channel timelocks remain similar. For more information on this vulnerability, one can refer to the Flood & Loot paper. However, solutions to fix this vulnerability have been proposed such as pull requests 764 and 772 on the lightning-rfc GitHub repository. Further discussion on this topic can be found on the Bitcoin-dev mailing list archive.
Updated on: 2023-06-03T02:56:22.201229+00:00