-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all,
Today we are writing to disclose the details of CVE-2020-26895 as a follow up to the partial disclosure sent to lightning-dev [1]. ## Abstract 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. Though 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. We have no evidence of the bug being exploited in the wild. It affects all classes of lnd nodes: routing, merchant, mobile, etc. The vulnerability was reported privately to the lnd team by Antoine Riard. ## Background 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. For regular, on-chain transactions, signature serialization is handled by the btcec library's Signature.Serialize() method [2]. This method always normalizes signatures to their low-S variant before performing the DER-encoding to ensure that the btcec library can't _produce_ high-S signatures. Early in lnd's history, however, serialization modeled off btcec was added to produce DER-encoded signatures directly from the fixed-width representation, bypassing the conversion into big.Int representation used internally by btcec. In doing so, retaining the low-S normalization behavior was overlooked, and so Sig.ToSignatureBytes() [3] would return high-S DER signatures whenever the fixed-size signature was encoded with a high-S value. 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. On the other hand, lnd’s cooperative close fully verifies the remote party’s signatures using full policy-aware verification. As a result, the only exploitation vector occurs during the force close scenario. ## Updates to Lighting RFC 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. Riard has confirmed that he is planning to submit an update to the specification incorporating these recommendations. ## Patch 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 [4], which requires the passed object to have a Serialize() method. lnwire.Sig does not have a Serialize() method, and so cannot satisfy the interface. As a result, the relevant call sites were updated to pass in a btcec.Signature, forcing witness signature serialization through btcec's Serialize() method which includes low-S normalization. Note: A high-S signature can be converted to a low-S one manually w/o software changes, or by a 3rd party, assuming one is aware of the reason for rejection. Though the above recommendation to the spec by Riard also mitigates the issue, 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. 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. ## Timeline 04/03/2020 - Initial report from Antoine Riard 04/10/2020 - PR 4172 merged into master 04/29/2020 - lnd v0.10.0-beta released 08/20/2020 - lnd v0.11.0-beta released 10/08/2020 - Partial Disclosure sent to lightning-dev and lnd mailing list [1] 10/20/2020 - Full Disclosure sent to lightning-dev and lnd mailing list ## References [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002819.html [2] https://github.com/btcsuite/btcd/blob/ba530c4abb35ea824a1d3c01d74969b5564c3b08/btcec/signature.go#L47 [3] https://github.com/lightningnetwork/lnd/blob/0f94b8dc624cf0e96ddc8fe1b8e3bf4b3fc4c074/lnwire/signature.go#L92 [4] https://github.com/lightningnetwork/lnd/pull/4172 [5] https://gist.github.com/ariard/fb432a9d2cd3ba24fdc18ccc8c5c6eb4 Huge thanks to Antoine Riard for the responsible disclosure and for helping to make lnd more safu. More information can be found in Antoine’s disclosure [5]. Regards, Conner Fromknecht -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl+PWykACgkQ59c3tn+l ksf7Yg//WqZjtkw4Ol1fsbK+lfAkt6UENAq6Pja4/ZatkFI+U9Of3SwCNA5aAP1p XSSk4tQptNJi3o8IoUSGLuFZVOzc6SB/vrU3l+MMVcAfgnSj1N5rqW1OLv3Lm/fH Jz8eSvPtSEdtFt1JOC1VEd4ZEukjB8T6P/d4yudptUTk0tMrkLhLcN7byflxttU/ vG2JTtLl0uO+A2rhHkNvoUYqNLEOQssoAmShEBu+8uK56xGkRJQoBWvWN+yJDWor MsI9awUzWrvlGU4qCD2WxVWjK7/SXK7cz4PC1XaNr0RqhucXm6lL2wn4r/G1Qqx6 z6ztMG3rHNnLI43Y1DVn2qPiLyhx1cBe/X8U9EUmA1jDv3zCKo9MmRx1gS69DQx+ rWBx3N6AIevs3aU6fF2IrwMfrX/0Xb0HT/fIDq1qhN46UZaxJTUuRkQkpJHNNajI ze5mmussTg/cdPlSkYTt7/h0CgWN6DAEGVYp6hsPqGoH7jrsEB+wRtsihHRAXevX dcHZRoB4OG/oKs5vYZk2LIRKr1miNSdas5T0rJA7voGMMJEa5L8nKqGfzMXsudAv n+gVXCLPx3KjTF8yQrNu277ptGIy4AG71MQoOdxkzLtbzm2vfyDMNd14Qk3KWHVz NACF4EXcq+oebSIj5kkiNx2jei0hdYVJGPHp8XkewRb0KuB2yDw= =Sd09 -----END PGP SIGNATURE----- _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
