Author: Conner Fromknecht 2020-10-20 21:52:27
Published on: 2020-10-20T21:52:27+00:00
The Lightning Network Daemon (LND) team has disclosed a vulnerability, CVE-2020-26895, that affects all classes of LND nodes. Prior to v0.10.0-beta, a malicious peer could force an LND node to accept a high-S ECDSA signature when updating new off-chain states. Although the signatures are valid according to consensus rules, the mempool policy would reject transactions containing high-S values, potentially leading to loss of funds if time-sensitive transactions cannot be relayed and confirmed. The vulnerability was reported privately to the LND team by Antoine Riard. During unilateral closure, this can be exploited by an attacker to cause a second-level HTLC-success transaction from being accepted to the mempool. If the victim is unable to patch before the HTLC's CLTV expires, the attacker can then broadcast their HTLC-timeout transaction and recover the full value of the HTLC minus fees. The lightning-rfc specifies a fixed-width, 64-byte encoding used to transmit ECDSA signatures in the Lightning protocol, which differs from the DER-encoding used at the consensus layer.As noted by Riard during the process, the lightning-rfc is lacking in terms of specifying how nodes should validate signatures accepted off-chain. Notably, the signatures should be checked for conformation to both consensus and tx-relay standardness rules and rejected otherwise. This approach was chosen because it could retroactively patch affected nodes if they are upgraded before the HTLC deadline expires, as well as its covertness. After upgrading, any outstanding broadcasts would be reattempted, this time normalizing any previously-persisted high-S signatures into their low-S variant. This vulnerability was fixed in v0.10.0-beta by converting all witness construction methods in LND to accept signatures according to the input.Signature interface introduced in PR 4172, which requires the passed object to have a Serialize() method. Following the disclosure, LND will also introduce the full tx-relay standardness checks that are to be added to the lightning-rfc, as this offers a more general and complete approach to ensuring LND always adheres to standardness rules.The Lightning Network Daemon (LND) team has disclosed a vulnerability, CVE-2020-26895, that affects all classes of LND nodes. Prior to v0.10.0-beta, a malicious peer could force an LND node to accept a high-S ECDSA signature when updating new off-chain states. Although the signatures are valid according to consensus rules, the mempool policy would reject transactions containing high-S values, potentially leading to loss of funds if time-sensitive transactions cannot be relayed and confirmed. The vulnerability was reported privately to the LND team by Antoine Riard. During unilateral closure, this can be exploited by an attacker to cause a second-level HTLC-success transaction from being accepted to the mempool. If the victim is unable to patch before the HTLC's CLTV expires, the attacker can then broadcast their HTLC-timeout transaction and recover the full value of the HTLC minus fees. The lightning-rfc specifies a fixed-width, 64-byte encoding used to transmit ECDSA signatures in the Lightning protocol, which differs from the DER-encoding used at the consensus layer.As noted by Riard during the process, the lightning-rfc is lacking in terms of specifying how nodes should validate signatures accepted off-chain. Notably, the signatures should be checked for conformation to both consensus and tx-relay standardness rules and rejected otherwise. This approach was chosen because it could retroactively patch affected nodes if they are upgraded before the HTLC deadline expires, as well as its covertness. After upgrading, any outstanding broadcasts would be reattempted, this time normalizing any previously-persisted high-S signatures into their low-S variant. This vulnerability was fixed in v0.10.0-beta by converting all witness construction methods in LND to accept signatures according to the input.Signature interface introduced in PR 4172, which requires the passed object to have a Serialize() method. Following the disclosure, LND will also introduce the full tx-relay standardness checks that are to be added to the lightning-rfc, as this offers a more general and complete approach to ensuring LND always adheres to standardness rules.
Updated on: 2023-06-01T18:33:43.705391+00:00