From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3F756C0032; Sat, 21 Oct 2023 00:19:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1AF4E4F010; Sat, 21 Oct 2023 00:19:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1AF4E4F010 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=cOJl+jsa 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XR0P45BkSag; Sat, 21 Oct 2023 00:19:12 +0000 (UTC) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9F5414EE9C; Sat, 21 Oct 2023 00:19:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9F5414EE9C Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40806e4106dso8288475e9.1; Fri, 20 Oct 2023 17:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697847551; x=1698452351; 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=0AEyWHRZacswBXtkZtJc6lt2e5ea9aexlLX7UsgWESQ=; b=cOJl+jsaJLp0go5JwDsuWJONvPbjPdBxIZXky3egbnCn+skfCtnnhi/FOIQLTQfdSG JEfbc8o5M5U3TlIsYkUDHt3yKzYCISVgZgtX+4KHaCjKaJMsVcmcVUnDiKsMF2nBIKQQ 7skTeQrwcF8i9QRypWx1D8YTiHmn9BFJYschtWm78MFeGZwxGW0zCl4xPJqKPayNTRS6 ZVAvwfuVm2q3jYQIuNAZau/6ftuRcARV2VzKfjhr9qHyjgxRnsTclHKwPUJG7gw/TKOZ BxJMOyg+lhr6o7nGrIVYxz+Biv8BMcVF4M53uYkgsslVifH7MTC9MPYZsV3Dy0k3CwDM 6YhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697847551; x=1698452351; 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=0AEyWHRZacswBXtkZtJc6lt2e5ea9aexlLX7UsgWESQ=; b=TowSQb6LISV58zelx7MKcRQO6WpNna2m0RkomR4W4CvmS9rvy0SI/Hn11wspFqbZCm Dt8fPoCfjjWi94SjfhwHzaEeF835/PSpN286s4IHjSagqzifxUCBiQAbkWde5TcXJOO/ y3q/TJbTHw3kkQXx/0Qq8kLC/HNDS0MSF4v1X+sDPoQgsvsPhNhpIBcCGhDrrbxMUbHn CWARcbiMqUff+tGGvytgKMDJh9JAL7ShEdfTfD18xNYSsmHE9y4eJUzc5lw3gNMHcVc0 PeHdL9ZQheVjCLcsZnUHOea1/lE2ZrrytdUu+j1AknnJSiLD+bdo99n8AckTlmGSGB/e AEng== X-Gm-Message-State: AOJu0Yxwz9850m/9HVEKoGtKvLV5t17+vvM9XGi3NYeNsnHgmMQg7snR uZ6JpyPTkoXwPMrYsVf/x1c1OE2qK0S2gOIHtXM= X-Google-Smtp-Source: AGHT+IExKNv3BAymbFZuRtTmvtaSEz8Y5fOkjd4s+89Q3H4R7VPVC5v6pAnko/yRmZHAMb+mOVjBDreUC/v3pfrrxF8= X-Received: by 2002:a05:600c:3789:b0:3fe:d67d:5040 with SMTP id o9-20020a05600c378900b003fed67d5040mr6711185wmr.5.1697847550479; Fri, 20 Oct 2023 17:19:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olaoluwa Osuntokun Date: Fri, 20 Oct 2023 17:18:58 -0700 Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000002111c006082ef091" Cc: security@ariard.me, "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2023 00:19:14 -0000 --0000000000002111c006082ef091 Content-Type: text/plain; charset="UTF-8" > Let's say you have Alice, Bob and Caroll all "honest" routing hops > targeted by an attacker. They all have 3 independent 10 000 sats HTLC > in-flight on their outbound channels. > It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 sats (+ > rbf penalty 1 sat / vb rule 4). Alice's HTLC-timeout is out of network > mempools. > Bob broadcasts her HTLC-timeout of 200 000 sats at T+3. It is replaced by > Mallory at T+4 with her HLTC-preimage Y of 200 000 sats (+ rbf penalty 1 > sat / vb rule 4 * 2). Bob's HTLC-timeout is out of network mempools. IIRC correctly, in your scenario, you're dealing with Carol -> Bob -> Alice. Mallory can only replace an HTLC-timeout transaction if she's directly connected with the peer she's targeting via a direct channel. She cannot unilaterally replace any transaction in the mempool solely with knowledge of the preimage. All HTLC transactions are two party contracts, with the public keys of both participants hard coded into the contract. A third party cannot unilaterally sweep an HTLC given only a preimage. I think it's worth taking a minute to step back here so we can establish some fundamental context. Once the timelock of an HTLC expires, and the receiver has direct knowledge of the preimage, a bidding war begins. If the receiver is able to confirm their success transaction in time, then they gain the funds, and the sender is able to pipeline the preimage backwards in the route, making all parties whole. If the sender is the one that wins out, then it's as if nothing happened, sans the fees paid at the last mile, all other hops are able to safely cancel their HTLC back on the chain. As mentioned elsewhere in the thread, most implementations today will watch the mempool for preimages, so they can resolve the incoming HTLC as quickly as possible off chain. The attack described critically relies on the ability of an attacker to pull off very precise transaction replacement globally across "the mempool". If any of the honest parties see the preimage, in the mempool, then the attack ends as they can settle back off chain, and if their timeout is able to confirm first, then the defender has actually gained funds. In addition, such an attack needs to be executed perfectly, for hours if not days. Within the LN, all nodes set a security parameter, the CLTV delta, that dictates how much time they have before the outgoing and incoming HTLCs expire. Increasing this value makes the attack more difficult, as they must maintain the superposition of: fees low enough to not get mined, but high enough to replace the defender's transaction, but not _too_ high, as then it'll be mined and everything is over. With each iteration, the attacker is also forced to increase the amount of fees they pay, increasing the likely hood that the transaction will be mined. If mined, the attack is moot. As mentioned in the OP, one thing the attacker can do is try and locate the defender's node to launch the replacement attack directly in their mempool. However, by replacing directly in the mempool of the defender, the defender will learn of the preimage! They can use that to just settle everything back, thereby completing the payment, and stopping the attack short. Even ignoring direct access to the defender's mempool, the attacker needs to somehow iteratively execute the replacement across a real network, with all the network jitter, propagation delay, and geographic heterogeneity that entails. If they're off by milliseconds, then either a confirmation occurs, or the preimage is revealed in the mempool. A canned local regtest env is one thing, the distributed system that is the Internet is another. Returning back to the bidding war: for anchor channels, the second level HTLCs allow the defender to attach arbitrary inputs for fee bumping purposes. Using this, they can iteratively increase their fee (via RBF) as the expiry deadline approaches. With each step, they further increase the cost for the attacker. On top of that, this attack cannot be launched indiscriminately across the network. Instead, it requires per-node set up by the attacker, as they need to consume UTXOs to create a chain of transactions they'll use to launch the replacement attack. These also need to be maintained in a similar state of non-confirming superposition. That's all to say that imo, this is a rather fragile attack, which requires: per-node setup, extremely precise timing and execution, non-confirming superposition of all transactions, and instant propagation across the entire network of the replacement transaction (somehow also being obscured from the PoV of the defender). The attack can be launched directly with a miner, or "into" their mempool, but that weakens the attack as if the miner broadcasts any of the preimage replacement transactions, then the defender can once again use that to extract the preimage and settle the incoming HTLC. -- Laolu --0000000000002111c006082ef091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Let's say you have Alice, Bob and Caroll all &quo= t;honest" routing hops
> targeted by an attacker. They all have = 3 independent 10 000 sats HTLC
> in-flight on their outbound channels= .

> It is replaced by Mallory at T+2 with a HTLC-preimage X of 20= 0 000 sats (+
> rbf penalty 1 sat / vb rule 4). Alice's HTLC-time= out is out of network
> mempools.

> Bob broadcasts her HTLC= -timeout of 200 000 sats at T+3. It is replaced by
> Mallory at T+4 w= ith her HLTC-preimage Y of 200 000 sats (+ rbf penalty 1
> sat / vb r= ule 4 * 2). Bob's HTLC-timeout is out of network mempools.

IIRC= correctly, in your scenario, you're dealing with Carol -> Bob ->= Alice.
Mallory can only replace an HTLC-timeout transaction if she'= s directly
connected with the peer she's targeting via a direct chan= nel. She cannot
unilaterally replace any transaction in the mempool sole= ly with knowledge of
the preimage. All HTLC transactions are two party c= ontracts, with the public
keys of both participants hard coded into the = contract. A third party cannot
unilaterally sweep an HTLC given only a p= reimage.

I think it's worth taking a minute to step back here s= o we can establish
some fundamental context. Once the timelock of an HTL= C expires, and the
receiver has direct knowledge of the preimage, a bidd= ing war begins.=C2=A0 If the
receiver is able to confirm their success t= ransaction in time, then they
gain the funds, and the sender is able to = pipeline the preimage backwards in
the route, making all parties whole. = If the sender is the one that wins out,
then it's as if nothing happ= ened, sans the fees paid at the last mile, all
other hops are able to sa= fely cancel their HTLC back on the chain.

As mentioned elsewhere in = the thread, most implementations today will watch
the mempool for preima= ges, so they can resolve the incoming HTLC as quickly
as possible off ch= ain. The attack described critically relies on the ability
of an attacke= r to pull off very precise transaction replacement globally
across "= ;the mempool". If any of the honest parties see the preimage, in themempool, then the attack ends as they can settle back off chain, and iftheir timeout is able to confirm first, then the defender has actuallygained funds.

In addition, such an attack needs to be executed perf= ectly, for hours if not
days. Within the LN, all nodes set a security pa= rameter, the CLTV delta,
that dictates how much time they have before th= e outgoing and incoming HTLCs
expire. Increasing this value makes the at= tack more difficult, as they must
maintain the superposition of: fees lo= w enough to not get mined, but high
enough to replace the defender's= transaction, but not _too_ high, as then
it'll be mined and everyth= ing is over. With each iteration, the attacker is
also forced to increas= e the amount of fees they pay, increasing the likely
hood that the trans= action will be mined. If mined, the attack is moot.

As mentioned in = the OP, one thing the attacker can do is try and locate the
defender'= ;s node to launch the replacement attack directly in their mempool.
Howe= ver, by replacing directly in the mempool of the defender, the defender
= will learn of the preimage! They can use that to just settle everything
= back, thereby completing the payment, and stopping the attack short. Evenignoring direct access to the defender's mempool, the attacker needs = to
somehow iteratively execute the replacement across a real network, wi= th all
the network jitter, propagation delay, and geographic heterogenei= ty that
entails. If they're off by milliseconds, then either a confi= rmation occurs,
or the preimage is revealed in the mempool. A canned loc= al regtest env is
one thing, the distributed system that is the Internet= is another.

Returning back to the bidding war: for anchor channels,= the second level
HTLCs allow the defender to attach arbitrary inputs fo= r fee bumping
purposes. Using this, they can iteratively increase their = fee (via RBF) as
the expiry deadline approaches. With each step, they fu= rther increase the
cost for the attacker. On top of that, this attack ca= nnot be launched
indiscriminately across the network. Instead, it requir= es per-node set up by
the attacker, as they need to consume UTXOs to cre= ate a chain of
transactions they'll use to launch the replacement at= tack. These also need
to be maintained in a similar state of non-confirm= ing superposition.

That's all to say that imo, this is a rather = fragile attack, which requires:
per-node setup, extremely precise timing= and execution, non-confirming
superposition of all transactions, and in= stant propagation across the entire
network of the replacement transacti= on (somehow also being obscured from the
PoV of the defender). The attac= k can be launched directly with a miner, or
"into" their mempo= ol, but that weakens the attack as if the miner broadcasts
any of the pr= eimage replacement transactions, then the defender can once
again use th= at to extract the preimage and settle the incoming HTLC.

-- Laolu
--0000000000002111c006082ef091--