diff options
| author | Olaoluwa Osuntokun <laolu32@gmail.com> | 2023-10-16 15:51:19 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-10-16 22:51:35 +0000 |
| commit | 0d7c58f66542294bbed052f700599a8532d22027 (patch) | |
| tree | d4379b58b235cb74f91443516f404991e0266129 | |
| parent | 0ece89ae2b7c03b4799e98421019653bd44fc97d (diff) | |
| download | pi-bitcoindev-0d7c58f66542294bbed052f700599a8532d22027.tar.gz pi-bitcoindev-0d7c58f66542294bbed052f700599a8532d22027.zip | |
Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
| -rw-r--r-- | 90/5b078f9f41466618a334bf05deea36db3eb1db | 698 |
1 files changed, 698 insertions, 0 deletions
diff --git a/90/5b078f9f41466618a334bf05deea36db3eb1db b/90/5b078f9f41466618a334bf05deea36db3eb1db new file mode 100644 index 000000000..d5b87f73f --- /dev/null +++ b/90/5b078f9f41466618a334bf05deea36db3eb1db @@ -0,0 +1,698 @@ +Return-Path: <laolu32@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 85837C0032; + Mon, 16 Oct 2023 22:51:35 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 537F281430; + Mon, 16 Oct 2023 22:51:35 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 537F281430 +Authentication-Results: smtp1.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20230601 header.b=JxUoCuLi +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.848 +X-Spam-Level: +X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, + FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id izSQBNq6tcbk; Mon, 16 Oct 2023 22:51:33 +0000 (UTC) +Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com + [IPv6:2a00:1450:4864:20::331]) + by smtp1.osuosl.org (Postfix) with ESMTPS id AC42381391; + Mon, 16 Oct 2023 22:51:32 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AC42381391 +Received: by mail-wm1-x331.google.com with SMTP id + 5b1f17b1804b1-40651a72807so48487945e9.1; + Mon, 16 Oct 2023 15:51:32 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1697496691; x=1698101491; + darn=lists.linuxfoundation.org; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=Bt7xCsQrcbBX/j4bmVS4X86Y2yzELYDk7rHwy43hNoM=; + b=JxUoCuLiHnK+09z1O2U9Kp9lItGMBwcbJrJGMF76aKFZC4PQ7+YEereAueeM+fHCzO + 5AaKRzvD3YYbdgwemsfz9Fchw4Qa3//iOfCexiD3IsdI1cedYnep3yMrwtAj1S5aX26z + vxGpPvDjXBofnNY2g1uGKg+R9+++sBDGIvJYVekLiB0DNptmQmaDr7nsV0IFCp+mwd3Y + SRPcTxPZd2uDpVCIO1YzjzYmvRZWtSKUwK+5mg98xRfL+qZtNIkN5Rz6hjml/iCYu9IH + VMb2jN63kuRVNty1dyVIXuMrsomA02mMuY9Zv3kKFdj0UHdP0xEsnxRFq6Pkf6B+bTUJ + r1Wg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1697496691; x=1698101491; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id + :reply-to; + bh=Bt7xCsQrcbBX/j4bmVS4X86Y2yzELYDk7rHwy43hNoM=; + b=gDdO165GetRT30Ooo0W0jL3we30KhhOAlFhBKwl2saS8/FI8LaXPEkh/xUuIMlSmYD + iFw80v1YSF51ZWHDdVV9zhxrNfODQFaUd+AKzM3FLcZJ2Ky8Jqv/iIhC5RFtJL/Rqh58 + lZ62ksi8u7kWSszOT8QbngUwCBCYZK9HlbUf2hl1bWotwNAsN1nXGZnFil+C0UWHGixL + LI1uugrs9f8jUN364fM3QkskwFepLuzJ/McZJJphDVKx9Z9gY2SAse5XUBf4pweFats9 + 5iGHogXw3GlC3h+mxZSFRyW9eS4yabFnQvz9YwgJgYGeZGeNIVweXCTmEtdfiMNARQo9 + uXIw== +X-Gm-Message-State: AOJu0YwoJKAm8MoAV2VlZIQ8PUqS/4Yf/o2CILtGYqLM0fyq0NJLPDlc + b3syE2G1XWPtZf07tyOGVo0HMKfPpAMYTWP9JjBrhJ4jQxQ= +X-Google-Smtp-Source: AGHT+IGAWsn8UNSR6UJ0n1RfT91IOwzCuXwURXLWhMRTKXyMvwJFPpZWGt5ZgWjTANJQWc/FI8FbcElHzxypiQNsAG4= +X-Received: by 2002:a05:6000:b4a:b0:32d:bdca:b243 with SMTP id + dk10-20020a0560000b4a00b0032dbdcab243mr618183wrb.14.1697496690500; Mon, 16 + Oct 2023 15:51:30 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com> +In-Reply-To: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com> +From: Olaoluwa Osuntokun <laolu32@gmail.com> +Date: Mon, 16 Oct 2023 15:51:19 -0700 +Message-ID: <CAO3Pvs_9yGsXyiXfwv_jjLCi8PZt8k_vafagbQJfv=6JBY8J3g@mail.gmail.com> +To: Antoine Riard <antoine.riard@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000003eaaaf0607dd3ff4" +Cc: "lightning-dev\\\\@lists.linuxfoundation.org" + <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 + / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 16 Oct 2023 22:51:35 -0000 + +--0000000000003eaaaf0607dd3ff4 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Antoine, + +Thanks for this great write up, and also your diligence in reporting this +issue to the various implementations, and game planning with us re +mitigations and attack scenarios. + +One small clarification: all of lnd's relevant mitigations were in place by +lnd v0.16.1-beta [1], which was released on April 24th 2023. Since then +we've fixed some performance regressions introduced due to some of the +mitigations (mempool watching), and in 0.17.1 we'll start to use the new +`gettxspendingprevout` RPC call with bitcoind to further reduce load. + +[1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta + +-- Laolu + +On Mon, Oct 16, 2023 at 10:04=E2=80=AFAM Antoine Riard via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> (cross-posting mempool issues identified are exposing lightning chan to +> loss of funds risks, other multi-party bitcoin apps might be affected) +> +> Hi, +> +> End of last year (December 2022), amid technical discussions on eltoo +> payment channels and incentives compatibility of the mempool anti-DoS +> rules, a new transaction-relay jamming attack affecting lightning channel= +s +> was discovered. +> +> After careful analysis, it turns out this attack is practical and +> immediately exposed lightning routing hops carrying HTLC traffic to loss = +of +> funds security risks, both legacy and anchor output channels. A potential +> exploitation plausibly happening even without network mempools congestion= +. +> +> Mitigations have been designed, implemented and deployed by all major +> lightning implementations during the last months. +> +> Please find attached the release numbers, where the mitigations should be +> present: +> - LDK: v0.0.118 - CVE-2023 -40231 +> - Eclair: v0.9.0 - CVE-2023-40232 +> - LND: v.0.17.0-beta - CVE-2023-40233 +> - Core-Lightning: v.23.08.01 - CVE-2023-40234 +> +> While neither replacement cycling attacks have been observed or reported +> in the wild since the last ~10 months or experimented in real-world +> conditions on bitcoin mainet, functional test is available exercising the +> affected lightning channel against bitcoin core mempool (26.0 release +> cycle). +> +> It is understood that a simple replacement cycling attack does not demand +> privileged capabilities from an attacker (e.g no low-hashrate power) and +> only access to basic bitcoin and lightning software. Yet I still think +> executing such an attack successfully requests a fair amount of bitcoin +> technical know-how and decent preparation. +> +> From my understanding of those issues, it is yet to be determined if the +> mitigations deployed are robust enough in face of advanced replacement +> cycling attackers, especially ones able to combine different classes of +> transaction-relay jamming such as pinnings or vetted with more privileged +> capabilities. +> +> Please find a list of potential affected bitcoin applications in this ful= +l +> disclosure report using bitcoin script timelocks or multi-party +> transactions, albeit no immediate security risk exposure as severe as the +> ones affecting lightning has been identified. Only cursory review of +> non-lightning applications has been conducted so far. +> +> There is a paper published summarizing replacement cycling attacks on the +> lightning network: +> +> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper= +/replacement-cycling.pdf +> +> ## Problem +> +> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted +> HTLC on incoming link and offered HTLC on outgoing link) should settle th= +e +> outgoing state with either a success or timeout before the incoming state +> timelock becomes final and an asymmetric defavorable settlement might +> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network" +> section 2.3 for a classical exposition of this lightning security propert= +y). +> +> Failure to satisfy this settlement requirement exposes a forwarding hop t= +o +> a loss of fund risk where the offered HTLC is spent by the outgoing link +> counterparty's HTLC-preimage and the accepted HTLC is spent by the incomi= +ng +> link counterparty's HTLC-timeout. +> +> The specification mandates the incoming HTLC expiration timelock to be +> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC +> expiration timelock, this exact interval value being an implementation an= +d +> node policy setting. As a minimal value, the specification recommends 34 +> blocks of interval. If the timelock expiration I of the inbound HTLC is +> equal to 100 from chain tip, the timelock expiration O of the outbound HT= +LC +> must be equal to 66 blocks from chain tip, giving a reasonable buffer of +> reaction to the lightning forwarding node. +> +> In the lack of cooperative off-chain settlement of the HTLC on the +> outgoing link negotiated with the counterparty (either +> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the +> lightning node should broadcast its commitment transaction. Once the +> commitment is confirmed (if anchor and the 1 CSV encumbrance is present), +> the lightning node broadcasts and confirms its HTLC-timeout before I heig= +ht +> is reached. +> +> Here enter a replacement cycling attack. A malicious channel counterparty +> can broadcast its HTLC-preimage transaction with a higher absolute fee an= +d +> higher feerate than the honest HTLC-timeout of the victim lightning node +> and triggers a replacement. Both for legacy and anchor output channels, a +> HTLC-preimage on a counterparty commitment transaction is malleable, i.e +> additional inputs or outputs can be added. The HTLC-preimage spends an +> unconfirmed and unrelated to the channel parent transaction M and conflic= +ts +> its child. +> +> As the HTLC-preimage spends an unconfirmed input that was already include= +d +> in the unconfirmed and unrelated child transaction (rule 2), pays an +> absolute higher fee of at least the sum paid by the HTLC-timeout and chil= +d +> transaction (rule 3) and the HTLC-preimage feerate is greater than all +> directly conflicting transactions (rule 6), the replacement is accepted. +> The honest HTLC-timeout is evicted out of the mempool. +> +> In an ulterior move, the malicious counterparty can replace the parent +> transaction itself with another candidate N satisfying the replacement +> rules, triggering the eviction of the malicious HTLC-preimage from the +> mempool as it was a child of the parent T. +> +> There is no spending candidate of the offered HTLC output for the current +> block laying in network mempools. +> +> This replacement cycling tricks can be repeated for each rebroadcast +> attempt of the HTLC-timeout by the honest lightning node until expiration +> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeou= +t +> is broadcast by the counterparty's on the incoming link in collusion with +> the one on the outgoing link broadcasting its own HTLC-preimage. +> +> The honest Lightning node has been "double-spent" in its HTLC forwarding. +> +> As a notable factor impacting the success of the attack, a lightning +> node's honest HTLC-timeout might be included in the block template of the +> miner winning the block race and therefore realizes a spent of the offere= +d +> output. In practice, a replacement cycling attack might over-connect to +> miners' mempools and public reachable nodes to succeed in a fast eviction +> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can +> come with a better ancestor-score, it should be picked up on the flight b= +y +> economically competitive miners. +> +> A functional test exercising a simple replacement cycling of a HTLC +> transaction on bitcoin core mempool is available: +> https://github.com/ariard/bitcoin/commits/2023-test-mempool +> +> ## Deployed LN mitigations +> +> Aggressive rebroadcasting: As the replacement cycling attacker benefits +> from the HTLC-timeout being usually broadcast by lightning nodes only onc= +e +> every block, or less the replacement cycling malicious transactions paid +> only equal the sum of the absolute fees paid by the HTLC, adjusted with t= +he +> replacement penalty. Rebroadcasting randomly and multiple times before th= +e +> next block increases the absolute fee cost for the attacker. +> +> Implemented and deployed by Eclair, Core-Lightning, LND and LDK . +> +> Local-mempool preimage monitoring: As the replacement cycling attacker in +> a simple setup broadcast the HTLC-preimage to all the network mempools, t= +he +> honest lightning node is able to catch on the flight the unconfirmed +> HTLC-preimage, before its subsequent mempool replacement. The preimage ca= +n +> be extracted from the second-stage HTLC-preimage and used to fetch the +> off-chain inbound HTLC with a cooperative message or go on-chain with it = +to +> claim the accepted HTLC output. +> +> Implemented and deployed by Eclair and LND. +> +> CLTV Expiry Delta: With every jammed block comes an absolute fee cost pai= +d +> by the attacker, a risk of the HTLC-preimage being detected or discovered +> by the honest lightning node, or the HTLC-timeout to slip in a winning +> block template. Bumping the default CLTV delta hardens the odds of succes= +s +> of a simple replacement cycling attack. +> +> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72. +> +> ## Affected Bitcoin Protocols and Applications +> +> From my understanding the following list of Bitcoin protocols and +> applications could be affected by new denial-of-service vectors under som= +e +> level of network mempools congestion. Neither tests or advanced review of +> specifications (when available) has been conducted for each of them: +> - on-chain DLCs +> - coinjoins +> - payjoins +> - wallets with time-sensitive paths +> - peerswap and submarine swaps +> - batch payouts +> - transaction "accelerators" +> +> Inviting their developers, maintainers and operators to investigate how +> replacement cycling attacks might disrupt their in-mempool chain of +> transactions, or fee-bumping flows at the shortest delay. Simple flows an= +d +> non-multi-party transactions should not be affected to the best of my +> understanding. +> +> ## Open Problems: Package Malleability +> +> Pinning attacks have been known for years as a practical vector to +> compromise lightning channels funds safety, under different scenarios (cf= +. +> current bip331's motivation section). Mitigations at the mempool level ha= +ve +> been designed, discussed and are under implementation by the community +> (ancestor package relay + nverrsion=3D3 policy). Ideally, they should +> constraint a pinning attacker to always attach a high feerate package +> (commitment + CPFP) to replace the honest package, or allow a honest +> lightning node to overbid a malicious pinning package and get its +> time-sensitive transaction optimistically included in the chain. +> +> Replacement cycling attack seem to offer a new way to neutralize the +> design goals of package relay and its companion nversion=3D3 policy, wher= +e an +> attacker package RBF a honest package out of the mempool to subsequently +> double-spend its own high-fee child with a transaction unrelated to the +> channel. As the remaining commitment transaction is pre-signed with a +> minimal relay fee, it can be evicted out of the mempool. +> +> A functional test exercising a simple replacement cycling of a lightning +> channel commitment transaction on top of the nversion=3D3 code branch is +> available: +> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 +> +> ## Discovery +> +> In 2018, the issue of static fees for pre-signed lightning transactions i= +s +> made more widely known, the carve-out exemption in mempool rules to +> mitigate in-mempool package limits pinning and the anchor output pattern +> are proposed. +> +> In 2019, bitcoin core 0.19 is released with carve-out support. Continued +> discussion of the anchor output pattern as a dynamic fee-bumping method. +> +> In 2020, draft of anchor output submitted to the bolts. Initial finding o= +f +> economic pinning against lightning commitment and second-stage HTLC +> transactions. Subsequent discussions of a preimage-overlay network or +> package-relay as mitigations. Public call made to inquiry more on potenti= +al +> other transaction-relay jamming attacks affecting lightning. +> +> In 2021, initial work in bitcoin core 22.0 of package acceptance. +> Continued discussion of the pinning attacks and shortcomings of current +> mempool rules during community-wide online workshops. Later the year, in +> light of all issues for bitcoin second-layers, a proposal is made about +> killing the mempool. +> +> In 2022, bip proposed for package relay and new proposed v3 policy design +> proposed for a review and implementation. Mempoolfullrbf is supported in +> bitcoin core 24.0 and conceptual questions about alignment of mempool rul= +es +> w.r.t miners incentives are investigated. +> +> Along this year 2022, eltoo lightning channels design are discussed, +> implemented and reviewed. In this context and after discussions on mempoo= +l +> anti-DoS rules, I discovered this new replacement cycling attack was +> affecting deployed lightning channels and immediately reported the findin= +g +> to some bitcoin core developers and lightning maintainers. +> +> ## Timeline +> +> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg +> Sanders and Gloria Zhao +> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier= +, +> Matt Corallo and Olaoluwa Osuntunkun +> - 2022-12-23: Sharing to Eugene Siegel (LND) +> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightnin= +g +> potential affected projects) +> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layer= +s +> issuers) and initial proposal of an early public disclosure +> - 2022-01-19: Collection of analysis if other second-layers and +> multi-party applications affected. LN mitigations development starts. +> - 2023-05-04: Sharing to Wilmer Paulino (LDK) +> - 2023-06-20: LN mitigations implemented and progressively released. Week +> of the 16 october proposed for full disclosure. +> - 2023-08-10: CVEs assigned by MITRE +> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling +> attack existence to security@bitcoincore.org. +> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 / +> CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks +> +> ## Conclusion +> +> Despite the line of mitigations adopted and deployed by current major +> lightning implementations, I believe replacement cycling attacks are stil= +l +> practical for advanced attackers. Beyond this new attack might come as a +> way to partially or completely defeat some of the pinning mitigations whi= +ch +> have been working for years as a community. +> +> As of today, it is uncertain to me if lightning is not affected by a more +> severe long-term package malleability critical security issue under curre= +nt +> consensus rules, and if any other time-sensitive multi-party protocol, +> designed or deployed isn't de facto affected too (loss of funds or denial +> of service). +> +> Assuming analysis on package malleability is correct, it is unclear to me +> if it can be corrected by changes in replacement / eviction rules or +> mempool chain of transactions processing strategy. Inviting my technical +> peers and the bitcoin community to look more on this issue, including to +> dissent. I'll be the first one pleased if I'm fundamentally wrong on thos= +e +> issues, or if any element has not been weighted with the adequate technic= +al +> accuracy it deserves. +> +> Do not trust, verify. All mistakes and opinions are my own. +> +> Antoine +> +> "meet with Triumph and Disaster. And treat those two impostors just the +> same" - K. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000003eaaaf0607dd3ff4 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Antoine,=C2=A0<br><br>Thanks for this great write up, a= +nd also your diligence=C2=A0in reporting this<br>issue to the various imple= +mentations, and game planning with us re<br>mitigations and attack scenario= +s.=C2=A0<br><br>One small clarification: all of lnd's relevant mitigati= +ons were in place by<br>lnd v0.16.1-beta [1], which was released on April 2= +4th 2023. Since then<br>we've fixed some performance=C2=A0regressions= +=C2=A0introduced=C2=A0due to some of the<br>mitigations (mempool watching),= + and in 0.17.1 we'll start to=C2=A0use the new<br>`gettxspendingprevout= +` RPC call with bitcoind=C2=A0to further reduce load.=C2=A0<br><br>[1]:=C2= +=A0<a href=3D"https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-= +beta">https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta</a>= +<br><br>-- Laolu<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c= +lass=3D"gmail_attr">On Mon, Oct 16, 2023 at 10:04=E2=80=AFAM Antoine Riard = +via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org= +">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote= + class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= +lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>(cross-posting= + mempool issues identified are exposing lightning chan to loss of funds ris= +ks, other multi-party bitcoin apps might be affected)</div><div><br></div>H= +i,<div><br></div><div>End of last year (December 2022), amid technical disc= +ussions on eltoo payment channels and incentives compatibility of the mempo= +ol anti-DoS rules, a new transaction-relay jamming attack affecting lightni= +ng channels was discovered.</div><div><br></div><div>After careful analysis= +, it turns out this attack is practical and immediately=C2=A0exposed lightn= +ing routing hops carrying HTLC traffic to loss of funds security risks, bot= +h legacy and anchor=C2=A0output channels. A potential exploitation plausibl= +y happening even without network mempools congestion.</div><div><br></div><= +div>Mitigations have been designed, implemented and deployed by all major l= +ightning implementations during the last months.</div><div><br></div><div>P= +lease find attached the release numbers, where the mitigations should be pr= +esent:</div><div>- LDK: v0.0.118 - CVE-2023 -40231</div><div>- Eclair: v0.9= +.0 - CVE-2023-40232</div><div>- LND: v.0.17.0-beta - CVE-2023-40233</div><d= +iv>- Core-Lightning: v.23.08.01 - CVE-2023-40234</div><div><br></div><div>W= +hile neither replacement cycling attacks have been observed or reported in = +the wild since the last ~10 months or experimented in real-world conditions= + on bitcoin mainet, functional test is available exercising the affected li= +ghtning channel against bitcoin core mempool (26.0 release cycle).</div><di= +v><br></div><div>It is understood that a simple replacement cycling attack = +does not demand privileged capabilities from an attacker (e.g no low-hashra= +te power) and only access to basic bitcoin and lightning software. Yet I st= +ill think executing such an attack successfully requests a fair amount of b= +itcoin technical know-how and decent preparation.</div><div><br></div><div>= +From my understanding of those issues, it is yet to be determined if the mi= +tigations deployed are robust enough in face of advanced replacement cyclin= +g attackers, especially ones able to combine different classes of transacti= +on-relay jamming such as pinnings or vetted with more privileged capabiliti= +es.</div><div><br></div><div>Please find a list of potential affected bitco= +in applications in this full disclosure report using bitcoin script timeloc= +ks or multi-party transactions, albeit no immediate security risk exposure = +as severe as the ones affecting lightning has been identified. Only cursory= + review of non-lightning applications has been conducted so far.</div><div>= +<br></div><div>There is a paper published summarizing replacement cycling a= +ttacks on the lightning network:</div><div><a href=3D"https://github.com/ar= +iard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pd= +f" target=3D"_blank">https://github.com/ariard/mempool-research/blob/2023-1= +0-replacement-paper/replacement-cycling.pdf</a></div><div><br></div><div>= +=C2=A0## Problem</div><div><br></div><div>A lightning node allows HTLCs for= +warding (in bolt3's parlance accepted HTLC on incoming link and offered= + HTLC on outgoing link) should settle the outgoing state with either a succ= +ess or timeout before the incoming state timelock becomes final and an asym= +metric defavorable settlement might happen (cf "Flood & Loot: A Sy= +stematic Attack on The Lightning Network" section 2.3 for a classical = +exposition of this lightning security property).</div><div><br></div><div>F= +ailure to satisfy this settlement requirement exposes a forwarding hop to a= + loss of fund risk where the offered HTLC is spent by the outgoing link cou= +nterparty's HTLC-preimage and the accepted HTLC is spent by the incomin= +g link counterparty's HTLC-timeout.</div><div><br></div><div>The specif= +ication mandates the incoming HTLC expiration timelock to be spaced out by = +an interval of `cltv_expiry_delta` from the outgoing HTLC expiration timelo= +ck, this exact interval value being an implementation and node policy setti= +ng. As a minimal value, the specification recommends 34 blocks of interval.= + If the timelock expiration I of the inbound HTLC is equal to 100 from chai= +n tip, the timelock expiration O of the outbound HTLC must be equal to 66 b= +locks from chain tip, giving a reasonable buffer of reaction to the lightni= +ng forwarding node.</div><div><br></div><div>In the lack of cooperative off= +-chain settlement of the HTLC on the outgoing link negotiated with the coun= +terparty (either `update_fulfill_htlc` or `update_fail_htlc`) when O is rea= +ched, the lightning node should broadcast its commitment transaction. Once = +the commitment is confirmed (if anchor and the 1 CSV encumbrance is present= +), the lightning node broadcasts and confirms its HTLC-timeout before I hei= +ght is reached.</div><div><br></div><div>Here enter a replacement cycling a= +ttack. A malicious channel counterparty can broadcast its HTLC-preimage tra= +nsaction with a higher absolute fee and higher feerate than the honest HTLC= +-timeout of the victim lightning node and triggers a replacement. Both for = +legacy and anchor output channels, a HTLC-preimage on a counterparty commit= +ment transaction is malleable, i.e additional inputs or outputs can be adde= +d. The HTLC-preimage spends an unconfirmed and unrelated to the channel par= +ent transaction M and conflicts its child.</div><div><br></div><div>As the = +HTLC-preimage spends an unconfirmed input that was already included in the = +unconfirmed and unrelated child transaction (rule 2), pays an absolute high= +er fee of at least the sum paid by the HTLC-timeout and child transaction (= +rule 3) and the HTLC-preimage feerate is greater than all directly conflict= +ing transactions (rule 6), the replacement is accepted. The honest HTLC-tim= +eout is evicted out of the mempool.</div><div><br></div><div>In an ulterior= + move, the malicious counterparty can replace the parent transaction itself= + with another candidate N satisfying the replacement rules, triggering the = +eviction of the malicious HTLC-preimage from the mempool as it was a child = +of the parent T.</div><div><br></div><div>There is no spending candidate of= + the offered HTLC output for the current block laying in network mempools.<= +/div><div><br></div><div>This replacement cycling tricks can be repeated fo= +r each rebroadcast attempt of the HTLC-timeout by the honest lightning node= + until expiration of the inbound HTLC timelock I. Once this height is reach= +ed a HTLC-timeout is broadcast by the counterparty's on the incoming li= +nk in collusion with the one on the outgoing link broadcasting its own HTLC= +-preimage.</div><div><br></div><div>The honest Lightning node has been &quo= +t;double-spent" in its HTLC forwarding.</div><div><br></div><div>As a = +notable factor impacting the success of the attack, a lightning node's = +honest HTLC-timeout might be included in the block template of the miner wi= +nning the block race and therefore realizes a spent of the offered output. = +In practice, a replacement cycling attack might over-connect to miners'= + mempools and public reachable nodes to succeed in a fast eviction of the H= +TLC-timeout by its HTLC-preimage. As this latter transaction can come with = +a better ancestor-score, it should be picked up on the flight by economical= +ly competitive miners.</div><div><br></div><div>A functional test exercisin= +g a simple replacement cycling of a HTLC transaction on bitcoin core mempoo= +l is available:</div><div><a href=3D"https://github.com/ariard/bitcoin/comm= +its/2023-test-mempool" target=3D"_blank">https://github.com/ariard/bitcoin/= +commits/2023-test-mempool</a><br></div><div><br></div><div>## Deployed LN m= +itigations</div><div><br></div><div>Aggressive rebroadcasting: As the repla= +cement cycling attacker benefits from the HTLC-timeout being usually broadc= +ast by lightning nodes only once every block, or less the replacement cycli= +ng malicious transactions paid only equal the sum of the absolute fees paid= + by the HTLC, adjusted with the replacement penalty. Rebroadcasting randoml= +y and multiple times before the next block increases the absolute fee cost = +for the attacker.</div><div><br></div><div>Implemented and deployed by Ecla= +ir, Core-Lightning, LND and LDK .</div><div><br></div><div>Local-mempool pr= +eimage monitoring: As the replacement cycling attacker in a simple setup br= +oadcast the HTLC-preimage to all the network mempools, the honest lightning= + node is able to catch on the flight the unconfirmed HTLC-preimage, before = +its subsequent mempool replacement. The preimage can be extracted from the = +second-stage HTLC-preimage and used to fetch the off-chain inbound HTLC wit= +h a cooperative message or go on-chain with it to claim the accepted HTLC o= +utput.</div><div><br></div><div>Implemented and deployed by Eclair and LND.= +<br></div><div><br></div><div>CLTV Expiry Delta: With every jammed block co= +mes an absolute fee cost paid by the attacker, a risk of the HTLC-preimage = +being detected or discovered by the honest lightning node, or the HTLC-time= +out to slip in a winning block template. Bumping the default CLTV delta har= +dens the odds of success of a simple replacement cycling attack.</div><div>= +<br></div><div>Default setting: Eclair 144, Core-Lightning 34, LND 80 and L= +DK 72.</div><div><br></div><div>## Affected Bitcoin Protocols and Applicati= +ons</div><div><br></div><div>From my understanding the following list of Bi= +tcoin protocols and applications could be affected by new denial-of-service= + vectors under some level of network mempools congestion. Neither tests or = +advanced review of specifications (when available) has been conducted for e= +ach of them:</div><div>- on-chain DLCs</div><div>- coinjoins</div><div>- pa= +yjoins</div><div>- wallets with time-sensitive paths</div><div>- peerswap a= +nd submarine swaps</div><div>- batch payouts</div><div>- transaction "= +accelerators"</div><div><br></div><div>Inviting their developers, main= +tainers and operators to investigate how replacement cycling attacks might = +disrupt their in-mempool chain of transactions, or fee-bumping flows at the= + shortest delay. Simple flows and non-multi-party transactions should not b= +e affected to the best of my understanding.</div><div><br></div><div>## Ope= +n Problems: Package Malleability</div><div><br></div><div>Pinning attacks h= +ave been known for years as a practical vector to compromise lightning chan= +nels funds safety, under different scenarios (cf. current bip331's moti= +vation section). Mitigations at the mempool level have been designed, discu= +ssed and are under implementation by the community (ancestor package relay= +=C2=A0+ nverrsion=3D3 policy). Ideally, they should constraint a pinning at= +tacker to always attach a high feerate package (commitment=C2=A0+ CPFP) to = +replace the honest package, or allow a honest lightning node to overbid a m= +alicious pinning package and get its time-sensitive transaction optimistica= +lly included in the chain.</div><div><br></div><div>Replacement cycling att= +ack seem to offer a new way to neutralize the design goals of package relay= + and its companion nversion=3D3 policy, where an attacker package RBF a hon= +est package out of the mempool to subsequently double-spend its own high-fe= +e child with a transaction unrelated to the channel. As the remaining commi= +tment transaction is pre-signed with a minimal relay fee, it can be evicted= + out of the mempool.</div><div><br></div><div>A functional test exercising = +a simple replacement cycling of a lightning channel commitment transaction = +on top of the nversion=3D3 code branch is available:</div><div><a href=3D"h= +ttps://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2" target=3D"= +_blank">https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a= +><br></div><div><br></div><div>## Discovery</div><div><br></div><div>In 201= +8, the issue of static fees for pre-signed lightning transactions is made m= +ore widely known, the carve-out exemption in mempool rules to mitigate in-m= +empool package limits pinning and the anchor output pattern are proposed.</= +div><div><br></div><div>In 2019, bitcoin core 0.19 is released with carve-o= +ut support. Continued discussion of the anchor output pattern as a dynamic = +fee-bumping method.</div><div><br></div><div>In 2020, draft of anchor outpu= +t submitted to the bolts. Initial finding of economic pinning against light= +ning commitment and second-stage HTLC transactions. Subsequent discussions = +of a preimage-overlay network or package-relay as mitigations. Public call = +made to inquiry more on potential other transaction-relay jamming attacks a= +ffecting lightning.</div><div><br></div><div>In 2021, initial work in bitco= +in core 22.0 of package acceptance. Continued discussion of the pinning att= +acks and shortcomings of current mempool rules during community-wide online= + workshops. Later the year, in light of all issues for bitcoin second-layer= +s, a proposal is made about killing the mempool.</div><div><br></div><div>I= +n 2022, bip proposed for package relay and new proposed v3 policy design pr= +oposed for a review and implementation. Mempoolfullrbf is supported in bitc= +oin core 24.0 and conceptual questions about alignment of mempool rules w.r= +.t miners incentives are investigated.</div><div><br></div><div>Along this = +year 2022, eltoo lightning channels design are discussed, implemented and r= +eviewed. In this context and after discussions on mempool anti-DoS rules, I= + discovered this new replacement cycling attack was affecting deployed ligh= +tning channels and immediately reported the finding to some bitcoin core de= +velopers and lightning maintainers.</div><div><br></div><div>## Timeline</d= +iv><div><br></div><div>- 2022-12-16: Report of the finding to Suhas Daftuar= +, Anthony Towns, Greg Sanders and Gloria Zhao</div><div>- 2022-12-16: Repor= +t to LN maintainers: Rusty Russell, Bastien Teinturier, Matt Corallo and Ol= +aoluwa Osuntunkun</div><div>- 2022-12-23: Sharing to Eugene Siegel (LND)</d= +iv><div>- 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (no= +n-lightning potential affected projects)</div><div>- 2022-01-14: Sharing to= + Gleb Naumenko (miners incentives and cross-layers issuers) and initial pro= +posal of an early public disclosure=C2=A0</div><div>- 2022-01-19: Collectio= +n of analysis if other second-layers and multi-party applications affected.= + LN mitigations development starts.</div><div>- 2023-05-04: Sharing to Wilm= +er Paulino (LDK)</div><div>- 2023-06-20: LN mitigations implemented and pro= +gressively released. Week of the 16 october proposed for full disclosure.</= +div><div>- 2023-08-10: CVEs assigned by MITRE</div><div>- 2023-10-05: Pre-d= +isclosure of LN CVEs numbers and replacement cycling attack existence to <a= + href=3D"mailto:security@bitcoincore.org" target=3D"_blank">security@bitcoi= +ncore.org</a>.</div><div>- 2023-10-16: Full disclosure of CVE-2023-40231 / = +CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 and replacement cycling at= +tacks</div><div><br></div><div>## Conclusion=C2=A0</div><div><br></div><div= +>Despite the line of mitigations adopted and deployed by current major ligh= +tning implementations, I believe replacement cycling attacks are still prac= +tical for advanced attackers. Beyond this new attack might come as a way to= + partially or completely defeat some of the pinning mitigations which have = +been working for years as a community.</div><div><br></div><div>As of today= +, it is uncertain to me if lightning is not affected by a more severe long-= +term package malleability critical security issue under current consensus r= +ules, and if any other time-sensitive multi-party protocol, designed or dep= +loyed isn't de facto affected too (loss of funds or denial of service).= +</div><div><br></div><div>Assuming analysis on package malleability is corr= +ect, it is unclear to me if it can be corrected by changes in replacement /= + eviction rules or mempool chain of transactions processing strategy. Invit= +ing my technical peers and the bitcoin community to look more on this issue= +, including to dissent. I'll be the first one pleased if I'm fundam= +entally wrong on those issues, or if any element has not been weighted with= + the adequate technical accuracy it deserves.</div><div><br></div><div>Do n= +ot trust, verify. All mistakes and opinions are my own.</div><div><br></div= +><div>Antoine</div><div><br></div><div>"meet with Triumph and Disaster= +. And treat those two impostors just the same" - K.</div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000003eaaaf0607dd3ff4-- + |