diff options
| author | Bastien TEINTURIER <bastien@acinq.fr> | 2023-10-19 10:12:08 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-10-19 08:12:26 +0000 |
| commit | 48f2412b3b174cae67c5a15caf6a3f3c5f65cbc5 (patch) | |
| tree | 61482df42ee2aeb605016ccc63d432b0572dbba3 | |
| parent | 0b12e82722f4fbcda2948dc6d8dff59bb005fbbd (diff) | |
| download | pi-bitcoindev-48f2412b3b174cae67c5a15caf6a3f3c5f65cbc5.tar.gz pi-bitcoindev-48f2412b3b174cae67c5a15caf6a3f3c5f65cbc5.zip | |
Re: [bitcoin-dev] [Lightning-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-- | 27/7800a8b809c53dc7c970b75d1e42adc0bc881f | 1124 |
1 files changed, 1124 insertions, 0 deletions
diff --git a/27/7800a8b809c53dc7c970b75d1e42adc0bc881f b/27/7800a8b809c53dc7c970b75d1e42adc0bc881f new file mode 100644 index 000000000..47de731a3 --- /dev/null +++ b/27/7800a8b809c53dc7c970b75d1e42adc0bc881f @@ -0,0 +1,1124 @@ +Return-Path: <bastien.teinturier@acinq.fr> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 052CFC0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 Oct 2023 08:12:26 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id DF515424C9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 Oct 2023 08:12:25 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DF515424C9 +Authentication-Results: smtp2.osuosl.org; + dkim=pass (2048-bit key) header.d=acinq.fr header.i=@acinq.fr + header.a=rsa-sha256 header.s=google header.b=GwgMSFIT +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.088 +X-Spam-Level: +X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] + autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 2BfDDeH1Q2BD + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 Oct 2023 08:12:22 +0000 (UTC) +Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com + [IPv6:2a00:1450:4864:20::133]) + by smtp2.osuosl.org (Postfix) with ESMTPS id BC40A400C7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 Oct 2023 08:12:21 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org BC40A400C7 +Received: by mail-lf1-x133.google.com with SMTP id + 2adb3069b0e04-507a936f4a9so6001402e87.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 Oct 2023 01:12:21 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=acinq.fr; s=google; t=1697703139; x=1698307939; + 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=JC7/akCsGbOecDTAxWfbwLKp/Hdejpm70pMXWVoCyWE=; + b=GwgMSFIT1wZyoIqhzlCYEIMl70XoClC2DDb0BiaNzYvYn1dimFXQGU+upPD64uOg+j + jdJHaUiz+IIrzw6rUNDmnW7J93yQSrrnIgPouylkGIED7p5oADo+cNR/O9/TLT4T1rUG + sdpaVnrJYMhdmG3wj+emaawoMdiMnB+Q43O72Wa1dRoGPvdXQGKwAju1zXfpABm6206E + GwiumzN9ftK6bXkSW2Ll6pOhZAoxzR3HJ6Yqjlb3B92c4w0tuQwhMBA0TCDmnHO8JXS4 + 7GEUS0txBfZ5qiErH6srxweW2g7wc06LGpuokEb5ZhTKBJaQM/o1WulETJt6OhYUSV9L + Kglg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1697703139; x=1698307939; + 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=JC7/akCsGbOecDTAxWfbwLKp/Hdejpm70pMXWVoCyWE=; + b=o4kJz6j6VvYQoJSsrAy9hGFriAnw0PxqJXh9Jjk2tPPBxmOqDUBS69U/2O+j6Pd02p + cLSp9CysLsmJSgQa2zgCzRgjCpUmENAFXbm1cCPZMv4OaXTMI9qTzoFEqcsThaCChVz7 + fxDHbcWPpABP+BZlLORuqOe7YCFBpIg/byua/CwndB705XRUu2r1BlkaRFOZxFKOAdLD + QMSG73knkPI4D7ooTwWCBtOGKPcUzqHOMBHiYDW7Bx8mzhsZjVqfxiU1q8RcTXl+Can3 + HEFpjGUdXSDcuewLpToxBP4iuDGZBXD992mQETYZsK8KbB3WpBnKo2gNbG7MIcz1GZ6Z + NcoQ== +X-Gm-Message-State: AOJu0YyqT+ie6HQHZUlvuZNEJOh7kTxEcxaRSO/jHNcOj0ksPrW70cHU + m/vai3i1fSZeqhUviiMyz6ObSbPGqdlQ6KErRn8+gg== +X-Google-Smtp-Source: AGHT+IEJV/b4OQhjXfHxm2BE3Iq1LGXwSpOa8l+qfieyW+Bqo8b8TDoeC3OYcWzkT5Vvza0Id/nzg//9lBIfbLXpKYM= +X-Received: by 2002:ac2:47eb:0:b0:507:a66b:c9a1 with SMTP id + b11-20020ac247eb000000b00507a66bc9a1mr847497lfp.17.1697703139479; Thu, 19 Oct + 2023 01:12:19 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com> + <ece6f28b-5b14-4f9c-a115-945082a63d68@mattcorallo.com> + <CALZpt+FSn6ox9cnDVuWX0pjR-R_mxQCRTORR_XiPDEOVkx9YsA@mail.gmail.com> +In-Reply-To: <CALZpt+FSn6ox9cnDVuWX0pjR-R_mxQCRTORR_XiPDEOVkx9YsA@mail.gmail.com> +From: Bastien TEINTURIER <bastien@acinq.fr> +Date: Thu, 19 Oct 2023 10:12:08 +0200 +Message-ID: <CACdvm3N+R1KqQx6r-s0eBw111B7uhM=8yguSkggOsth_cZZC5w@mail.gmail.com> +To: Antoine Riard <antoine.riard@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000090385906080d509c" +X-Mailman-Approved-At: Thu, 19 Oct 2023 08:47:03 +0000 +Cc: "lightning-dev\\\\@lists.linuxfoundation.org" + <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [Lightning-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: Thu, 19 Oct 2023 08:12:26 -0000 + +--00000000000090385906080d509c +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks Antoine for your work on this issue. + +I confirm that eclair v0.9.0 contains the migitations described. + +Eclair has been watching the mempool for preimages since its very early +versions (years ago), relying on Bitcoin Core's ZMQ notifications for +incoming transactions. I believe this guarantees that we see the HTLC +success transaction, even if it is immediately replaced (as long as we +don't overflow the ZMQ limits). + +I agree with Matt though that more fundamental work most likely needs to +happen at the bitcoin layer to allow L2 protocols to be more robust +against that class of attacks. + +Thanks, +Bastien + +Le mer. 18 oct. 2023 =C3=A0 11:07, Antoine Riard via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : + +> The disclosure mails noted a 3rd mitigation beyond mempool scanning and +> transaction re-signing / re-broadcasting, namely bumping CLTV delta. +> +> Generally bumping CLTV delta is a basic line of mitigations for a lot of +> lightning attacks, as it gives opportunity to node operators to intervene +> and re-broadcast their time-sensitive transactions on other interfaces (e= +.g +> a secondary full-node if the first one is eclipsed). +> +> About the second mitigation transaction re-signing, if done correctly at +> least sounds to put an economic cost (denominated in fees / feerates) on +> the attack. This is unclear to me if the game-theory of this cost holds. +> +> One thing which sounds to me making the attack harder is stratum v2 +> deployment, as you're increasing the number of miners which might do thei= +r +> own block templates, and therefore the number of miners' mempools where a= +n +> attacker has to successfully continuously replace in cycles channels +> counterparties transactions. +> +> A replacement buffer or history of transactions at the mempool level migh= +t +> be a mitigation to this attack. I believe this is yet to be seen if it ca= +n +> be made robust enough. +> +> I don't know if folks like tadge or rusty who have been involved in the +> early design of lightning have more ideas of mitigations. Fees was noted = +as +> a hard issue in the original paper. +> +> Le mer. 18 oct. 2023 =C3=A0 01:17, Matt Corallo <lf-lists@mattcorallo.com= +> a +> =C3=A9crit : +> +>> There appears to be some confusion about this issue and the mitigations. +>> To be clear, the deployed +>> mitigations are not expected to fix this issue, its arguable if they +>> provide anything more than a PR +>> statement. +>> +>> There are two discussed mitigations here - mempool scanning and +>> transaction re-signing/re-broadcasting. +>> +>> Mempool scanning relies on regularly checking the mempool of a local nod= +e +>> to see if we can catch the +>> replacement cycle mid-cycle. It only works if wee see the first +>> transaction before the second +>> transaction replaces it. +>> +>> Today, a large majority of lightning nodes run on machines with a Bitcoi= +n +>> node on the same IP +>> address, making it very clear what the "local node" of the lightning nod= +e +>> is. An attacker can +>> trivially use this information to connect to said local node and do the +>> replacement quickly, +>> preventing the victim from seeing the replacement. +>> +>> More generally, however, similar discoverability is true for mining +>> pools. An attacker performing +>> this attack is likely to do the replacement attack on a miner's node +>> directly, potentially reducing +>> the reach of the intermediate transaction to only miners, such that the +>> victim can never discover it +>> at all. +>> +>> The second mitigation is similarly pathetic. Re-signing and +>> re-broadcasting the victim's transaction +>> in an attempt to get it to miners even if its been removed may work, if +>> the attacker is super lazy +>> and didn't finish writing their attack system. If the attacker is +>> connected to a large majority of +>> hashrate (which has historically been fairly doable), they can simply do +>> their replacement in a +>> cycle aggressively and arbitrarily reduce the probability that the +>> victim's transaction gets confirmed. +>> +>> Now, the above is all true in a spherical cow kinda world, and the P2P +>> network has plenty of slow +>> nodes and strange behavior. Its possible that these mitigations might, b= +y +>> some stroke of luck, +>> happen to catch such an attack and prevent it, because something took +>> longer than the attacker +>> intended or whatever. But, that's a far cry from any kind of material +>> "fix" for the issue. +>> +>> Ultimately the only fix for this issue will be when miners keep a histor= +y +>> of transactions they've +>> seen and try them again after they may be able to enter the mempool +>> because of an attack like this. +>> +>> Matt +>> +>> On 10/16/23 12:57 PM, Antoine Riard wrote: +>> > (cross-posting mempool issues identified are exposing lightning chan t= +o +>> 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 channels 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 +>> full 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-pape= +r/replacement-cycling.pdf +>> > < +>> https://github.com/ariard/mempool-research/blob/2023-10-replacement-pape= +r/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 the 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 property). +>> > +>> > Failure to satisfy this settlement requirement exposes a forwarding ho= +p +>> to 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 incoming 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 and 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 HTLC 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 height is reached. +>> > +>> > Here enter a replacement cycling attack. A malicious channel +>> counterparty can broadcast its +>> > HTLC-preimage transaction with a higher absolute fee and higher feerat= +e +>> 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 conflicts its child. +>> > +>> > As the HTLC-preimage spends an unconfirmed input that was already +>> included in the unconfirmed and +>> > unrelated child transaction (rule 2), pays an absolute higher fee of a= +t +>> least the sum paid by the +>> > HTLC-timeout and child 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 timeloc= +k +>> I. Once this height is +>> > reached a HTLC-timeout 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 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 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 by 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 +>> > <https://github.com/ariard/bitcoin/commits/2023-test-mempool> +>> > +>> > ## Deployed LN mitigations +>> > +>> > Aggressive rebroadcasting: As the replacement cycling attacker benefit= +s +>> from the HTLC-timeout being +>> > usually broadcast by lightning nodes only once every block, or less th= +e +>> replacement cycling +>> > malicious transactions paid only equal the sum of the absolute fees +>> paid by the HTLC, adjusted with +>> > the replacement penalty. Rebroadcasting randomly and multiple times +>> before the 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, 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 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 +>> paid 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 success 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 some 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 ho= +w +>> 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 be affected t= +o +>> 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 have 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 th= +e +>> 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, where 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 +>> > <https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2> +>> > +>> > ## Discovery +>> > +>> > In 2018, the issue of static fees for pre-signed lightning transaction= +s +>> is made more widely known, +>> > the carve-out exemption in mempool rules to mitigate in-mempool packag= +e +>> 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 findin= +g +>> of 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 +>> > potential 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 rules 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 mempool anti-DoS rules, I +>> discovered this new replacement +>> > cycling attack was affecting deployed lightning channels and +>> immediately reported the finding 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-lightning potential affected projects) +>> > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and +>> cross-layers 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 cyclin= +g +>> attack existence to +>> > security@bitcoincore.org <mailto: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 still practical 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. +>> > +>> > 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 rules, an= +d +>> 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 +>> those issues, or if any element +>> > has not been weighted with the adequate technical 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 th= +e +>> same" - K. +>> > +>> > _______________________________________________ +>> > Lightning-dev mailing list +>> > Lightning-dev@lists.linuxfoundation.org +>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev +>> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000090385906080d509c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Thanks Antoine for your work on this issue.<br><br>I confi= +rm that eclair v0.9.0 contains the migitations described.<br><br>Eclair has= + been watching the mempool for preimages since its very early<br>versions (= +years ago), relying on Bitcoin Core's ZMQ notifications for<br>incoming= + transactions. I believe this guarantees that we see the HTLC<br>success tr= +ansaction, even if it is immediately replaced (as long as we<br>don't o= +verflow the ZMQ limits).<br><br>I agree with Matt though that more fundamen= +tal work most likely needs to<br>happen at the bitcoin layer to allow L2 pr= +otocols to be more robust<br>against that class of attacks.<br><br>Thanks,<= +br>Bastien</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm= +ail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A011:07, Antoine Riard via bi= +tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= +oin-dev@lists.linuxfoundation.org</a>> a =C3=A9crit=C2=A0:<br></div><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= +:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The disclosu= +re mails noted a 3rd mitigation beyond=C2=A0mempool scanning and transactio= +n re-signing / re-broadcasting, namely bumping CLTV delta.<div><br></div><d= +iv>Generally bumping CLTV delta is a basic line of mitigations for a lot of= + lightning attacks, as it gives opportunity to node operators to intervene = +and re-broadcast their time-sensitive transactions on other interfaces (e.g= + a secondary full-node if the first one is eclipsed).</div><div><br></div><= +div>About the second mitigation transaction re-signing, if done correctly a= +t least sounds to put an economic cost (denominated in fees / feerates) on = +the attack. This is unclear to me if the game-theory of this cost holds.</d= +iv><div><br></div><div>One thing which sounds to me making the attack harde= +r is stratum v2 deployment, as you're increasing the number of miners w= +hich might do their own block templates, and therefore the number of miners= +' mempools where=C2=A0an attacker has to successfully continuously repl= +ace in cycles channels counterparties transactions.</div><div><br></div><di= +v>A replacement buffer or history of transactions at the mempool level migh= +t be a mitigation to this attack. I believe this is yet to be seen if it ca= +n be made robust enough.</div><div><br></div><div>I don't know if folks= + like tadge or rusty who have been involved in the early design of lightnin= +g have more ideas of mitigations. Fees was noted as a hard issue in the ori= +ginal paper.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla= +ss=3D"gmail_attr">Le=C2=A0mer. 18 oct. 2023 =C3=A0=C2=A001:17, Matt Corallo= + <<a href=3D"mailto:lf-lists@mattcorallo.com" target=3D"_blank">lf-lists= +@mattcorallo.com</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"= +gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= +4,204,204);padding-left:1ex">There appears to be some confusion about this = +issue and the mitigations. To be clear, the deployed <br> +mitigations are not expected to fix this issue, its arguable if they provid= +e anything more than a PR <br> +statement.<br> +<br> +There are two discussed mitigations here - mempool scanning and transaction= + re-signing/re-broadcasting.<br> +<br> +Mempool scanning relies on regularly checking the mempool of a local node t= +o see if we can catch the <br> +replacement cycle mid-cycle. It only works if wee see the first transaction= + before the second <br> +transaction replaces it.<br> +<br> +Today, a large majority of lightning nodes run on machines with a Bitcoin n= +ode on the same IP <br> +address, making it very clear what the "local node" of the lightn= +ing node is. An attacker can <br> +trivially use this information to connect to said local node and do the rep= +lacement quickly, <br> +preventing the victim from seeing the replacement.<br> +<br> +More generally, however, similar discoverability is true for mining pools. = +An attacker performing <br> +this attack is likely to do the replacement attack on a miner's node di= +rectly, potentially reducing <br> +the reach of the intermediate transaction to only miners, such that the vic= +tim can never discover it <br> +at all.<br> +<br> +The second mitigation is similarly pathetic. Re-signing and re-broadcasting= + the victim's transaction <br> +in an attempt to get it to miners even if its been removed may work, if the= + attacker is super lazy <br> +and didn't finish writing their attack system. If the attacker is conne= +cted to a large majority of <br> +hashrate (which has historically been fairly doable), they can simply do th= +eir replacement in a <br> +cycle aggressively and arbitrarily reduce the probability that the victim&#= +39;s transaction gets confirmed.<br> +<br> +Now, the above is all true in a spherical cow kinda world, and the P2P netw= +ork has plenty of slow <br> +nodes and strange behavior. Its possible that these mitigations might, by s= +ome stroke of luck, <br> +happen to catch such an attack and prevent it, because something took longe= +r than the attacker <br> +intended or whatever. But, that's a far cry from any kind of material &= +quot;fix" for the issue.<br> +<br> +Ultimately the only fix for this issue will be when miners keep a history o= +f transactions they've <br> +seen and try them again after they may be able to enter the mempool because= + of an attack like this.<br> +<br> +Matt<br> +<br> +On 10/16/23 12:57 PM, Antoine Riard wrote:<br> +> (cross-posting mempool issues identified are exposing lightning chan t= +o loss of funds risks, other <br> +> multi-party bitcoin apps might be affected)<br> +> <br> +> Hi,<br> +> <br> +> End of last year (December 2022), amid technical discussions on eltoo = +payment channels and <br> +> incentives compatibility of the mempool anti-DoS rules, a new transact= +ion-relay jamming attack <br> +> affecting lightning channels was discovered.<br> +> <br> +> After careful analysis, it turns out this attack is practical and imme= +diately=C2=A0exposed lightning <br> +> routing hops carrying HTLC traffic to loss of funds security risks, bo= +th legacy and anchor=C2=A0output <br> +> channels. A potential exploitation plausibly happening even without ne= +twork mempools congestion.<br> +> <br> +> Mitigations have been designed, implemented and deployed by all major = +lightning implementations <br> +> during the last months.<br> +> <br> +> Please find attached the release numbers, where the mitigations should= + be present:<br> +> - LDK: v0.0.118 - CVE-2023 -40231<br> +> - Eclair: v0.9.0 - CVE-2023-40232<br> +> - LND: v.0.17.0-beta - CVE-2023-40233<br> +> - Core-Lightning: v.23.08.01 - CVE-2023-40234<br> +> <br> +> While neither replacement cycling attacks have been observed or report= +ed in the wild since the last <br> +> ~10 months or experimented in real-world conditions on bitcoin mainet,= + functional test is available <br> +> exercising the affected lightning channel against bitcoin core mempool= + (26.0 release cycle).<br> +> <br> +> It is understood that a simple replacement cycling attack does not dem= +and privileged capabilities <br> +> from an attacker (e.g no low-hashrate power) and only access to basic = +bitcoin and lightning <br> +> software. Yet I still think executing such an attack successfully requ= +ests a fair amount of bitcoin <br> +> technical know-how and decent preparation.<br> +> <br> +>=C2=A0 From my understanding of those issues, it is yet to be determine= +d if the mitigations deployed are <br> +> robust enough in face of advanced replacement cycling attackers, espec= +ially ones able to combine <br> +> different classes of transaction-relay jamming such as pinnings or vet= +ted with more privileged <br> +> capabilities.<br> +> <br> +> Please find a list of potential affected bitcoin applications in this = +full disclosure report using <br> +> bitcoin script timelocks or multi-party transactions, albeit no immedi= +ate security risk exposure as <br> +> severe as the ones affecting lightning has been identified. Only curso= +ry review of non-lightning <br> +> applications has been conducted so far.<br> +> <br> +> There is a paper published summarizing replacement cycling attacks on = +the lightning network:<br> +> <a href=3D"https://github.com/ariard/mempool-research/blob/2023-10-rep= +lacement-paper/replacement-cycling.pdf" rel=3D"noreferrer" target=3D"_blank= +">https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper= +/replacement-cycling.pdf</a> <br> +> <<a href=3D"https://github.com/ariard/mempool-research/blob/2023-10= +-replacement-paper/replacement-cycling.pdf" rel=3D"noreferrer" target=3D"_b= +lank">https://github.com/ariard/mempool-research/blob/2023-10-replacement-p= +aper/replacement-cycling.pdf</a>><br> +> <br> +>=C2=A0 =C2=A0## Problem<br> +> <br> +> A lightning node allows HTLCs forwarding (in bolt3's parlance acce= +pted HTLC on incoming link and <br> +> offered HTLC on outgoing link) should settle the outgoing state with e= +ither a success or timeout <br> +> before the incoming state timelock becomes final and an asymmetric def= +avorable settlement might <br> +> happen (cf "Flood & Loot: A Systematic Attack on The Lightnin= +g Network" section 2.3 for a classical <br> +> exposition of this lightning security property).<br> +> <br> +> Failure to satisfy this settlement requirement exposes a forwarding ho= +p to a loss of fund risk where <br> +> the offered HTLC is spent by the outgoing link counterparty's HTLC= +-preimage and the accepted HTLC is <br> +> spent by the incoming link counterparty's HTLC-timeout.<br> +> <br> +> The specification mandates the incoming HTLC expiration timelock to be= + spaced out by an interval of <br> +> `cltv_expiry_delta` from the outgoing HTLC expiration timelock, this e= +xact interval value being an <br> +> implementation and node policy setting. As a minimal value, the specif= +ication recommends 34 blocks <br> +> of interval. If the timelock expiration I of the inbound HTLC is equal= + to 100 from chain tip, the <br> +> timelock expiration O of the outbound HTLC must be equal to 66 blocks = +from chain tip, giving a <br> +> reasonable buffer of reaction to the lightning forwarding node.<br> +> <br> +> In the lack of cooperative off-chain settlement of the HTLC on the out= +going link negotiated with the <br> +> counterparty (either `update_fulfill_htlc` or `update_fail_htlc`) when= + O is reached, the lightning <br> +> node should broadcast its commitment transaction. Once the commitment = +is confirmed (if anchor and <br> +> the 1 CSV encumbrance is present), the lightning node broadcasts and c= +onfirms its HTLC-timeout <br> +> before I height is reached.<br> +> <br> +> Here enter a replacement cycling attack. A malicious channel counterpa= +rty can broadcast its <br> +> HTLC-preimage transaction with a higher absolute fee and higher feerat= +e than the honest HTLC-timeout <br> +> of the victim lightning node and triggers a replacement. Both for lega= +cy and anchor output channels, <br> +> a HTLC-preimage on a counterparty commitment transaction is malleable,= + i.e additional inputs or <br> +> outputs can be added. The HTLC-preimage spends an unconfirmed and unre= +lated to the channel parent <br> +> transaction M and conflicts its child.<br> +> <br> +> As the HTLC-preimage spends an unconfirmed input that was already incl= +uded in the unconfirmed and <br> +> unrelated child transaction (rule 2), pays an absolute higher fee of a= +t least the sum paid by the <br> +> HTLC-timeout and child transaction (rule 3) and the HTLC-preimage feer= +ate is greater than all <br> +> directly conflicting transactions (rule 6), the replacement is accepte= +d. The honest HTLC-timeout is <br> +> evicted out of the mempool.<br> +> <br> +> In an ulterior move, the malicious counterparty can replace the parent= + transaction itself with <br> +> another candidate N satisfying the replacement rules, triggering the e= +viction of the malicious <br> +> HTLC-preimage from the mempool as it was a child of the parent T.<br> +> <br> +> There is no spending candidate of the offered HTLC output for the curr= +ent block laying in network <br> +> mempools.<br> +> <br> +> This replacement cycling tricks can be repeated for each rebroadcast a= +ttempt of the HTLC-timeout by <br> +> the honest lightning node until expiration of the inbound HTLC timeloc= +k I. Once this height is <br> +> reached a HTLC-timeout is broadcast by the counterparty's on the i= +ncoming link in collusion with the <br> +> one on the outgoing link broadcasting its own HTLC-preimage.<br> +> <br> +> The honest Lightning node has been "double-spent" in its HTL= +C forwarding.<br> +> <br> +> As a notable factor impacting the success of the attack, a lightning n= +ode's honest HTLC-timeout <br> +> might be included in the block template of the miner winning the block= + race and therefore realizes a <br> +> spent of the offered output. In practice, a replacement cycling attack= + might over-connect to miners' <br> +> mempools and public reachable nodes to succeed in a fast eviction of t= +he HTLC-timeout by its <br> +> HTLC-preimage. As this latter transaction can come with a better ances= +tor-score, it should be picked <br> +> up on the flight by economically competitive miners.<br> +> <br> +> A functional test exercising a simple replacement cycling of a HTLC tr= +ansaction on bitcoin core <br> +> mempool is available:<br> +> <a href=3D"https://github.com/ariard/bitcoin/commits/2023-test-mempool= +" rel=3D"noreferrer" target=3D"_blank">https://github.com/ariard/bitcoin/co= +mmits/2023-test-mempool</a> <br> +> <<a href=3D"https://github.com/ariard/bitcoin/commits/2023-test-mem= +pool" rel=3D"noreferrer" target=3D"_blank">https://github.com/ariard/bitcoi= +n/commits/2023-test-mempool</a>><br> +> <br> +> ## Deployed LN mitigations<br> +> <br> +> Aggressive rebroadcasting: As the replacement cycling attacker benefit= +s from the HTLC-timeout being <br> +> usually broadcast by lightning nodes only once every block, or less th= +e replacement cycling <br> +> malicious transactions paid only equal the sum of the absolute fees pa= +id by the HTLC, adjusted with <br> +> the replacement penalty. Rebroadcasting randomly and multiple times be= +fore the next block increases <br> +> the absolute fee cost for the attacker.<br> +> <br> +> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .<br> +> <br> +> Local-mempool preimage monitoring: As the replacement cycling attacker= + in a simple setup broadcast <br> +> the HTLC-preimage to all the network mempools, the honest lightning no= +de is able to catch on the <br> +> flight the unconfirmed HTLC-preimage, before its subsequent mempool re= +placement. The preimage can be <br> +> extracted from the second-stage HTLC-preimage and used to fetch the of= +f-chain inbound HTLC with a <br> +> cooperative message or go on-chain with it to claim the accepted HTLC = +output.<br> +> <br> +> Implemented and deployed by Eclair and LND.<br> +> <br> +> CLTV Expiry Delta: With every jammed block comes an absolute fee cost = +paid by the attacker, a risk <br> +> of the HTLC-preimage being detected or discovered by the honest lightn= +ing node, or the HTLC-timeout <br> +> to slip in a winning block template. Bumping the default CLTV delta ha= +rdens the odds of success of a <br> +> simple replacement cycling attack.<br> +> <br> +> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.<br> +> <br> +> ## Affected Bitcoin Protocols and Applications<br> +> <br> +>=C2=A0 From my understanding the following list of Bitcoin protocols an= +d applications could be affected by <br> +> new denial-of-service vectors under some level of network mempools con= +gestion. Neither tests or <br> +> advanced review of specifications (when available) has been conducted = +for each of them:<br> +> - on-chain DLCs<br> +> - coinjoins<br> +> - payjoins<br> +> - wallets with time-sensitive paths<br> +> - peerswap and submarine swaps<br> +> - batch payouts<br> +> - transaction "accelerators"<br> +> <br> +> Inviting their developers, maintainers and operators to investigate ho= +w replacement cycling attacks <br> +> might disrupt their in-mempool chain of transactions, or fee-bumping f= +lows at the shortest delay. <br> +> Simple flows and non-multi-party transactions should not be affected t= +o the best of my understanding.<br> +> <br> +> ## Open Problems: Package Malleability<br> +> <br> +> Pinning attacks have been known for years as a practical vector to com= +promise lightning channels <br> +> funds safety, under different scenarios (cf. current bip331's moti= +vation section). Mitigations at <br> +> the mempool level have been designed, discussed and are under implemen= +tation by the community <br> +> (ancestor package relay=C2=A0+ nverrsion=3D3 policy). Ideally, they sh= +ould constraint a pinning attacker to <br> +> always attach a high feerate package (commitment=C2=A0+ CPFP) to repla= +ce the honest package, or allow a <br> +> honest lightning node to overbid a malicious pinning package and get i= +ts time-sensitive transaction <br> +> optimistically included in the chain.<br> +> <br> +> Replacement cycling attack seem to offer a new way to neutralize the d= +esign goals of package relay <br> +> and its companion nversion=3D3 policy, where an attacker package RBF a= + honest package out of the <br> +> mempool to subsequently double-spend its own high-fee child with a tra= +nsaction unrelated to the <br> +> channel. As the remaining commitment transaction is pre-signed with a = +minimal relay fee, it can be <br> +> evicted out of the mempool.<br> +> <br> +> A functional test exercising a simple replacement cycling of a lightni= +ng channel commitment <br> +> transaction on top of the nversion=3D3 code branch is available:<br> +> <a href=3D"https://github.com/ariard/bitcoin/commits/2023-10-test-memp= +ool-2" rel=3D"noreferrer" target=3D"_blank">https://github.com/ariard/bitco= +in/commits/2023-10-test-mempool-2</a> <br> +> <<a href=3D"https://github.com/ariard/bitcoin/commits/2023-10-test-= +mempool-2" rel=3D"noreferrer" target=3D"_blank">https://github.com/ariard/b= +itcoin/commits/2023-10-test-mempool-2</a>><br> +> <br> +> ## Discovery<br> +> <br> +> In 2018, the issue of static fees for pre-signed lightning transaction= +s is made more widely known, <br> +> the carve-out exemption in mempool rules to mitigate in-mempool packag= +e limits pinning and the <br> +> anchor output pattern are proposed.<br> +> <br> +> In 2019, bitcoin core 0.19 is released with carve-out support. Continu= +ed discussion of the anchor <br> +> output pattern as a dynamic fee-bumping method.<br> +> <br> +> In 2020, draft of anchor output submitted to the bolts. Initial findin= +g of economic pinning against <br> +> lightning commitment and second-stage HTLC transactions. Subsequent di= +scussions of a <br> +> preimage-overlay network or package-relay as mitigations. Public call = +made to inquiry more on <br> +> potential other transaction-relay jamming attacks affecting lightning.= +<br> +> <br> +> In 2021, initial work in bitcoin core 22.0 of package acceptance. Cont= +inued discussion of the <br> +> pinning attacks and shortcomings of current mempool rules during commu= +nity-wide online workshops. <br> +> Later the year, in light of all issues for bitcoin second-layers, a pr= +oposal is made about killing <br> +> the mempool.<br> +> <br> +> In 2022, bip proposed for package relay and new proposed v3 policy des= +ign proposed for a review and <br> +> implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and c= +onceptual questions about <br> +> alignment of mempool rules w.r.t miners incentives are investigated.<b= +r> +> <br> +> Along this year 2022, eltoo lightning channels design are discussed, i= +mplemented and reviewed. In <br> +> this context and after discussions on mempool anti-DoS rules, I discov= +ered this new replacement <br> +> cycling attack was affecting deployed lightning channels and immediate= +ly reported the finding to <br> +> some bitcoin core developers and lightning maintainers.<br> +> <br> +> ## Timeline<br> +> <br> +> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, G= +reg Sanders and Gloria Zhao<br> +> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teintur= +ier, Matt Corallo and Olaoluwa <br> +> Osuntunkun<br> +> - 2022-12-23: Sharing to Eugene Siegel (LND)<br> +> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-l= +ightning potential affected projects)<br> +> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-la= +yers issuers) and initial <br> +> proposal of an early public disclosure<br> +> - 2022-01-19: Collection of analysis if other second-layers and multi-= +party applications affected. <br> +> LN mitigations development starts.<br> +> - 2023-05-04: Sharing to Wilmer Paulino (LDK)<br> +> - 2023-06-20: LN mitigations implemented and progressively released. W= +eek of the 16 october proposed <br> +> for full disclosure.<br> +> - 2023-08-10: CVEs assigned by MITRE<br> +> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cyclin= +g attack existence to <br> +> <a href=3D"mailto:security@bitcoincore.org" target=3D"_blank">security= +@bitcoincore.org</a> <mailto:<a href=3D"mailto:security@bitcoincore.org"= + target=3D"_blank">security@bitcoincore.org</a>>.<br> +> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 / CVE= +-2023-40233 / CVE-2023-40234 <br> +> and replacement cycling attacks<br> +> <br> +> ## Conclusion<br> +> <br> +> Despite the line of mitigations adopted and deployed by current major = +lightning implementations, I <br> +> believe replacement cycling attacks are still practical for advanced a= +ttackers. Beyond this new <br> +> attack might come as a way to partially or completely defeat some of t= +he pinning mitigations which <br> +> have been working for years as a community.<br> +> <br> +> As of today, it is uncertain to me if lightning is not affected by a m= +ore severe long-term package <br> +> malleability critical security issue under current consensus rules, an= +d if any other time-sensitive <br> +> multi-party protocol, designed or deployed isn't de facto affected= + too (loss of funds or denial of <br> +> service).<br> +> <br> +> Assuming analysis on package malleability is correct, it is unclear to= + me if it can be corrected by <br> +> changes in replacement / eviction rules or mempool chain of transactio= +ns processing strategy. <br> +> Inviting my technical peers and the bitcoin community to look more on = +this issue, including to <br> +> dissent. I'll be the first one pleased if I'm fundamentally wr= +ong on those issues, or if any element <br> +> has not been weighted with the adequate technical accuracy it deserves= +.<br> +> <br> +> Do not trust, verify. All mistakes and opinions are my own.<br> +> <br> +> Antoine<br> +> <br> +> "meet with Triumph and Disaster. And treat those two impostors ju= +st the same" - K.<br> +> <br> +> _______________________________________________<br> +> Lightning-dev mailing list<br> +> <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_= +blank">Lightning-dev@lists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightnin= +g-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.o= +rg/mailman/listinfo/lightning-dev</a><br> +</blockquote></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> + +--00000000000090385906080d509c-- + + |