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"

From: Olaoluwa Osuntokun <laolu32@gmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
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"
Date: Fri, 20 Oct 2023 17:18:58 -0700	[thread overview]
Message-ID: <CAO3Pvs9jUr8cw0Dz35oHLREzSeMCbGyFkUDt0w8EFoW1RVZHzw@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+FaYop1J5Zi=42F4jCScfiPL3AZ98HWtW82Qd8ZQG=aMg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 5328 bytes --]