{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-10-16\n🗒️ Summary of this message: Cross-posting mempool issues have exposed lightning channels to the risk of loss of funds, potentially affecting other multi-party bitcoin applications. Mitigations have been implemented, but their effectiveness against advanced replacement cycling attacks is still uncertain.\n📝 Original message:\n(cross-posting mempool issues identified are exposing lightning chan to\nloss of funds risks, other multi-party bitcoin apps might be affected)\n\nHi,\n\nEnd of last year (December 2022), amid technical discussions on eltoo\npayment channels and incentives compatibility of the mempool anti-DoS\nrules, a new transaction-relay jamming attack affecting lightning channels\nwas discovered.\n\nAfter careful analysis, it turns out this attack is practical and\nimmediately exposed lightning routing hops carrying HTLC traffic to loss of\nfunds security risks, both legacy and anchor output channels. A potential\nexploitation plausibly happening even without network mempools congestion.\n\nMitigations have been designed, implemented and deployed by all major\nlightning implementations during the last months.\n\nPlease find attached the release numbers, where the mitigations should be\npresent:\n- LDK: v0.0.118 - CVE-2023 -40231\n- Eclair: v0.9.0 - CVE-2023-40232\n- LND: v.0.17.0-beta - CVE-2023-40233\n- Core-Lightning: v.23.08.01 - CVE-2023-40234\n\nWhile neither replacement cycling attacks have been observed or reported in\nthe wild since the last ~10 months or experimented in real-world conditions\non bitcoin mainet, functional test is available exercising the affected\nlightning channel against bitcoin core mempool (26.0 release cycle).\n\nIt is understood that a simple replacement cycling attack does not demand\nprivileged capabilities from an attacker (e.g no low-hashrate power) and\nonly access to basic bitcoin and lightning software. Yet I still think\nexecuting such an attack successfully requests a fair amount of bitcoin\ntechnical know-how and decent preparation.\n\n\u003eFrom my understanding of those issues, it is yet to be determined if the\nmitigations deployed are robust enough in face of advanced replacement\ncycling attackers, especially ones able to combine different classes of\ntransaction-relay jamming such as pinnings or vetted with more privileged\ncapabilities.\n\nPlease find a list of potential affected bitcoin applications in this full\ndisclosure report using bitcoin script timelocks or multi-party\ntransactions, albeit no immediate security risk exposure as severe as the\nones affecting lightning has been identified. Only cursory review of\nnon-lightning applications has been conducted so far.\n\nThere is a paper published summarizing replacement cycling attacks on the\nlightning network:\nhttps://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf\n\n ## Problem\n\nA lightning node allows HTLCs forwarding (in bolt3's parlance accepted HTLC\non incoming link and offered HTLC on outgoing link) should settle the\noutgoing state with either a success or timeout before the incoming state\ntimelock becomes final and an asymmetric defavorable settlement might\nhappen (cf \"Flood \u0026 Loot: A Systematic Attack on The Lightning Network\"\nsection 2.3 for a classical exposition of this lightning security property).\n\nFailure to satisfy this settlement requirement exposes a forwarding hop to\na loss of fund risk where the offered HTLC is spent by the outgoing link\ncounterparty's HTLC-preimage and the accepted HTLC is spent by the incoming\nlink counterparty's HTLC-timeout.\n\nThe specification mandates the incoming HTLC expiration timelock to be\nspaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC\nexpiration timelock, this exact interval value being an implementation and\nnode policy setting. As a minimal value, the specification recommends 34\nblocks of interval. If the timelock expiration I of the inbound HTLC is\nequal to 100 from chain tip, the timelock expiration O of the outbound HTLC\nmust be equal to 66 blocks from chain tip, giving a reasonable buffer of\nreaction to the lightning forwarding node.\n\nIn the lack of cooperative off-chain settlement of the HTLC on the outgoing\nlink negotiated with the counterparty (either `update_fulfill_htlc` or\n`update_fail_htlc`) when O is reached, the lightning node should broadcast\nits commitment transaction. Once the commitment is confirmed (if anchor and\nthe 1 CSV encumbrance is present), the lightning node broadcasts and\nconfirms its HTLC-timeout before I height is reached.\n\nHere enter a replacement cycling attack. A malicious channel counterparty\ncan broadcast its HTLC-preimage transaction with a higher absolute fee and\nhigher feerate than the honest HTLC-timeout of the victim lightning node\nand triggers a replacement. Both for legacy and anchor output channels, a\nHTLC-preimage on a counterparty commitment transaction is malleable, i.e\nadditional inputs or outputs can be added. The HTLC-preimage spends an\nunconfirmed and unrelated to the channel parent transaction M and conflicts\nits child.\n\nAs the HTLC-preimage spends an unconfirmed input that was already included\nin the unconfirmed and unrelated child transaction (rule 2), pays an\nabsolute higher fee of at least the sum paid by the HTLC-timeout and child\ntransaction (rule 3) and the HTLC-preimage feerate is greater than all\ndirectly conflicting transactions (rule 6), the replacement is accepted.\nThe honest HTLC-timeout is evicted out of the mempool.\n\nIn an ulterior move, the malicious counterparty can replace the parent\ntransaction itself with another candidate N satisfying the replacement\nrules, triggering the eviction of the malicious HTLC-preimage from the\nmempool as it was a child of the parent T.\n\nThere is no spending candidate of the offered HTLC output for the current\nblock laying in network mempools.\n\nThis replacement cycling tricks can be repeated for each rebroadcast\nattempt of the HTLC-timeout by the honest lightning node until expiration\nof the inbound HTLC timelock I. Once this height is reached a HTLC-timeout\nis broadcast by the counterparty's on the incoming link in collusion with\nthe one on the outgoing link broadcasting its own HTLC-preimage.\n\nThe honest Lightning node has been \"double-spent\" in its HTLC forwarding.\n\nAs a notable factor impacting the success of the attack, a lightning node's\nhonest HTLC-timeout might be included in the block template of the miner\nwinning the block race and therefore realizes a spent of the offered\noutput. In practice, a replacement cycling attack might over-connect to\nminers' mempools and public reachable nodes to succeed in a fast eviction\nof the HTLC-timeout by its HTLC-preimage. As this latter transaction can\ncome with a better ancestor-score, it should be picked up on the flight by\neconomically competitive miners.\n\nA functional test exercising a simple replacement cycling of a HTLC\ntransaction on bitcoin core mempool is available:\nhttps://github.com/ariard/bitcoin/commits/2023-test-mempool\n\n## Deployed LN mitigations\n\nAggressive rebroadcasting: As the replacement cycling attacker benefits\nfrom the HTLC-timeout being usually broadcast by lightning nodes only once\nevery block, or less the replacement cycling malicious transactions paid\nonly equal the sum of the absolute fees paid by the HTLC, adjusted with the\nreplacement penalty. Rebroadcasting randomly and multiple times before the\nnext block increases the absolute fee cost for the attacker.\n\nImplemented and deployed by Eclair, Core-Lightning, LND and LDK .\n\nLocal-mempool preimage monitoring: As the replacement cycling attacker in a\nsimple setup broadcast the HTLC-preimage to all the network mempools, the\nhonest lightning node is able to catch on the flight the unconfirmed\nHTLC-preimage, before its subsequent mempool replacement. The preimage can\nbe extracted from the second-stage HTLC-preimage and used to fetch the\noff-chain inbound HTLC with a cooperative message or go on-chain with it to\nclaim the accepted HTLC output.\n\nImplemented and deployed by Eclair and LND.\n\nCLTV Expiry Delta: With every jammed block comes an absolute fee cost paid\nby the attacker, a risk of the HTLC-preimage being detected or discovered\nby the honest lightning node, or the HTLC-timeout to slip in a winning\nblock template. Bumping the default CLTV delta hardens the odds of success\nof a simple replacement cycling attack.\n\nDefault setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.\n\n## Affected Bitcoin Protocols and Applications\n\n\u003eFrom my understanding the following list of Bitcoin protocols and\napplications could be affected by new denial-of-service vectors under some\nlevel of network mempools congestion. Neither tests or advanced review of\nspecifications (when available) has been conducted for each of them:\n- on-chain DLCs\n- coinjoins\n- payjoins\n- wallets with time-sensitive paths\n- peerswap and submarine swaps\n- batch payouts\n- transaction \"accelerators\"\n\nInviting their developers, maintainers and operators to investigate how\nreplacement cycling attacks might disrupt their in-mempool chain of\ntransactions, or fee-bumping flows at the shortest delay. Simple flows and\nnon-multi-party transactions should not be affected to the best of my\nunderstanding.\n\n## Open Problems: Package Malleability\n\nPinning attacks have been known for years as a practical vector to\ncompromise lightning channels funds safety, under different scenarios (cf.\ncurrent bip331's motivation section). Mitigations at the mempool level have\nbeen designed, discussed and are under implementation by the community\n(ancestor package relay + nverrsion=3 policy). Ideally, they should\nconstraint a pinning attacker to always attach a high feerate package\n(commitment + CPFP) to replace the honest package, or allow a honest\nlightning node to overbid a malicious pinning package and get its\ntime-sensitive transaction optimistically included in the chain.\n\nReplacement cycling attack seem to offer a new way to neutralize the design\ngoals of package relay and its companion nversion=3 policy, where an\nattacker package RBF a honest package out of the mempool to subsequently\ndouble-spend its own high-fee child with a transaction unrelated to the\nchannel. As the remaining commitment transaction is pre-signed with a\nminimal relay fee, it can be evicted out of the mempool.\n\nA functional test exercising a simple replacement cycling of a lightning\nchannel commitment transaction on top of the nversion=3 code branch is\navailable:\nhttps://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2\n\n## Discovery\n\nIn 2018, the issue of static fees for pre-signed lightning transactions is\nmade more widely known, the carve-out exemption in mempool rules to\nmitigate in-mempool package limits pinning and the anchor output pattern\nare proposed.\n\nIn 2019, bitcoin core 0.19 is released with carve-out support. Continued\ndiscussion of the anchor output pattern as a dynamic fee-bumping method.\n\nIn 2020, draft of anchor output submitted to the bolts. Initial finding of\neconomic pinning against lightning commitment and second-stage HTLC\ntransactions. Subsequent discussions of a preimage-overlay network or\npackage-relay as mitigations. Public call made to inquiry more on potential\nother transaction-relay jamming attacks affecting lightning.\n\nIn 2021, initial work in bitcoin core 22.0 of package acceptance. Continued\ndiscussion of the pinning attacks and shortcomings of current mempool rules\nduring community-wide online workshops. Later the year, in light of all\nissues for bitcoin second-layers, a proposal is made about killing the\nmempool.\n\nIn 2022, bip proposed for package relay and new proposed v3 policy design\nproposed for a review and implementation. Mempoolfullrbf is supported in\nbitcoin core 24.0 and conceptual questions about alignment of mempool rules\nw.r.t miners incentives are investigated.\n\nAlong this year 2022, eltoo lightning channels design are discussed,\nimplemented and reviewed. In this context and after discussions on mempool\nanti-DoS rules, I discovered this new replacement cycling attack was\naffecting deployed lightning channels and immediately reported the finding\nto some bitcoin core developers and lightning maintainers.\n\n## Timeline\n\n- 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg\nSanders and Gloria Zhao\n- 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,\nMatt Corallo and Olaoluwa Osuntunkun\n- 2022-12-23: Sharing to Eugene Siegel (LND)\n- 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning\npotential affected projects)\n- 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers\nissuers) and initial proposal of an early public disclosure\n- 2022-01-19: Collection of analysis if other second-layers and multi-party\napplications affected. LN mitigations development starts.\n- 2023-05-04: Sharing to Wilmer Paulino (LDK)\n- 2023-06-20: LN mitigations implemented and progressively released. Week\nof the 16 october proposed for full disclosure.\n- 2023-08-10: CVEs assigned by MITRE\n- 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling\nattack existence to security at bitcoincore.org.\n- 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /\nCVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks\n\n## Conclusion\n\nDespite the line of mitigations adopted and deployed by current major\nlightning implementations, I believe replacement cycling attacks are still\npractical for advanced attackers. Beyond this new attack might come as a\nway to partially or completely defeat some of the pinning mitigations which\nhave been working for years as a community.\n\nAs of today, it is uncertain to me if lightning is not affected by a more\nsevere long-term package malleability critical security issue under current\nconsensus rules, and if any other time-sensitive multi-party protocol,\ndesigned or deployed isn't de facto affected too (loss of funds or denial\nof service).\n\nAssuming analysis on package malleability is correct, it is unclear to me\nif it can be corrected by changes in replacement / eviction rules or\nmempool chain of transactions processing strategy. Inviting my technical\npeers and the bitcoin community to look more on this issue, including to\ndissent. I'll be the first one pleased if I'm fundamentally wrong on those\nissues, or if any element has not been weighted with the adequate technical\naccuracy it deserves.\n\nDo not trust, verify. All mistakes and opinions are my own.\n\nAntoine\n\n\"meet with Triumph and Disaster. And treat those two impostors just the\nsame\" - K.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231016/6e4e649f/attachment-0001.html\u003e"}