path: root/b8/43250372af98da437f591e4a5ef0b068bca414

Return-Path: <laolu32@gmail.com>
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: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ece6f28b-5b14-4f9c-a115-945082a63d68@mattcorallo.com>
 <CAGyamEWnSNAwJ1HpcgiYtNYwUqWOBn7RzhfR_W8460B_9n=qng@mail.gmail.com>
 <CALZpt+GaLGk_Yrnb9+CNm6psLdtiqw_DBkQt+gg8FGh87uN+0Q@mail.gmail.com>
 <CAGyamEXk6rNnFE1wztpbHqZVH_acN5AYb0Y7F2n2Nou1d_wdUA@mail.gmail.com>
 <CALZpt+FaYop1J5Zi=42F4jCScfiPL3AZ98HWtW82Qd8ZQG=aMg@mail.gmail.com>
In-Reply-To: <CALZpt+FaYop1J5Zi=42F4jCScfiPL3AZ98HWtW82Qd8ZQG=aMg@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 20 Oct 2023 17:18:58 -0700
Message-ID: <CAO3Pvs9jUr8cw0Dz35oHLREzSeMCbGyFkUDt0w8EFoW1RVZHzw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002111c006082ef091"
Cc: security@ariard.me, "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: 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

<div dir=3D"ltr">&gt; Let&#39;s say you have Alice, Bob and Caroll all &quo=
t;honest&quot; routing hops<br>&gt; targeted by an attacker. They all have =
3 independent 10 000 sats HTLC<br>&gt; in-flight on their outbound channels=
.<br><br>&gt; It is replaced by Mallory at T+2 with a HTLC-preimage X of 20=
0 000 sats (+<br>&gt; rbf penalty 1 sat / vb rule 4). Alice&#39;s HTLC-time=
out is out of network<br>&gt; mempools.<br><br>&gt; Bob broadcasts her HTLC=
-timeout of 200 000 sats at T+3. It is replaced by<br>&gt; Mallory at T+4 w=
ith her HLTC-preimage Y of 200 000 sats (+ rbf penalty 1<br>&gt; sat / vb r=
ule 4 * 2). Bob&#39;s HTLC-timeout is out of network mempools. <br><br>IIRC=
 correctly, in your scenario, you&#39;re dealing with Carol -&gt; Bob -&gt;=
 Alice.<br>Mallory can only replace an HTLC-timeout transaction if she&#39;=
s directly<br>connected with the peer she&#39;s targeting via a direct chan=
nel. She cannot<br>unilaterally replace any transaction in the mempool sole=
ly with knowledge of<br>the preimage. All HTLC transactions are two party c=
ontracts, with the public<br>keys of both participants hard coded into the =
contract. A third party cannot<br>unilaterally sweep an HTLC given only a p=
reimage. <br><br>I think it&#39;s worth taking a minute to step back here s=
o we can establish<br>some fundamental context. Once the timelock of an HTL=
C expires, and the<br>receiver has direct knowledge of the preimage, a bidd=
ing war begins.=C2=A0 If the<br>receiver is able to confirm their success t=
ransaction in time, then they<br>gain the funds, and the sender is able to =
pipeline the preimage backwards in<br>the route, making all parties whole. =
If the sender is the one that wins out,<br>then it&#39;s as if nothing happ=
ened, sans the fees paid at the last mile, all<br>other hops are able to sa=
fely cancel their HTLC back on the chain.<br><br>As mentioned elsewhere in =
the thread, most implementations today will watch<br>the mempool for preima=
ges, so they can resolve the incoming HTLC as quickly<br>as possible off ch=
ain. The attack described critically relies on the ability<br>of an attacke=
r to pull off very precise transaction replacement globally<br>across &quot=
;the mempool&quot;. If any of the honest parties see the preimage, in the<b=
r>mempool, then the attack ends as they can settle back off chain, and if<b=
r>their timeout is able to confirm first, then the defender has actually<br=
>gained funds.<br><br>In addition, such an attack needs to be executed perf=
ectly, for hours if not<br>days. Within the LN, all nodes set a security pa=
rameter, the CLTV delta,<br>that dictates how much time they have before th=
e outgoing and incoming HTLCs<br>expire. Increasing this value makes the at=
tack more difficult, as they must<br>maintain the superposition of: fees lo=
w enough to not get mined, but high<br>enough to replace the defender&#39;s=
 transaction, but not _too_ high, as then<br>it&#39;ll be mined and everyth=
ing is over. With each iteration, the attacker is<br>also forced to increas=
e the amount of fees they pay, increasing the likely<br>hood that the trans=
action will be mined. If mined, the attack is moot.<br><br>As mentioned in =
the OP, one thing the attacker can do is try and locate the<br>defender&#39=
;s node to launch the replacement attack directly in their mempool.<br>Howe=
ver, by replacing directly in the mempool of the defender, the defender<br>=
will learn of the preimage! They can use that to just settle everything<br>=
back, thereby completing the payment, and stopping the attack short. Even<b=
r>ignoring direct access to the defender&#39;s mempool, the attacker needs =
to<br>somehow iteratively execute the replacement across a real network, wi=
th all<br>the network jitter, propagation delay, and geographic heterogenei=
ty that<br>entails. If they&#39;re off by milliseconds, then either a confi=
rmation occurs,<br>or the preimage is revealed in the mempool. A canned loc=
al regtest env is<br>one thing, the distributed system that is the Internet=
 is another.<br><br>Returning back to the bidding war: for anchor channels,=
 the second level<br>HTLCs allow the defender to attach arbitrary inputs fo=
r fee bumping<br>purposes. Using this, they can iteratively increase their =
fee (via RBF) as<br>the expiry deadline approaches. With each step, they fu=
rther increase the<br>cost for the attacker. On top of that, this attack ca=
nnot be launched<br>indiscriminately across the network. Instead, it requir=
es per-node set up by<br>the attacker, as they need to consume UTXOs to cre=
ate a chain of<br>transactions they&#39;ll use to launch the replacement at=
tack. These also need<br>to be maintained in a similar state of non-confirm=
ing superposition.<br><br>That&#39;s all to say that imo, this is a rather =
fragile attack, which requires:<br>per-node setup, extremely precise timing=
 and execution, non-confirming<br>superposition of all transactions, and in=
stant propagation across the entire<br>network of the replacement transacti=
on (somehow also being obscured from the<br>PoV of the defender). The attac=
k can be launched directly with a miner, or<br>&quot;into&quot; their mempo=
ol, but that weakens the attack as if the miner broadcasts<br>any of the pr=
eimage replacement transactions, then the defender can once<br>again use th=
at to extract the preimage and settle the incoming HTLC.<br><br>-- Laolu<br=
></div>

--0000000000002111c006082ef091--