From: Antoine Riard <antoine.riard@gmail•com>
To: Olaoluwa Osuntokun <laolu32@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
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, 17 Nov 2023 22:36:35 +0000 [thread overview]
Message-ID: <CALZpt+F411Qv=8znxXzv6O3r21ZdD9h24RJL2Oq6O-mdBTaYww@mail.gmail.com> (raw)
In-Reply-To: <CAO3Pvs9jUr8cw0Dz35oHLREzSeMCbGyFkUDt0w8EFoW1RVZHzw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12641 bytes --]
> 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.
Correct mostly so far, a part of the globally across "the mempool".
> 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.
The attacker just has to overbid the parent of the HTLC-preimage with a
higher fee replacement parent. This replacement parent can be confirmed at
any time, even if the attacker realizes a higher economic gain if this
replacement transaction is delayed as much as possible. Or the absolute fee
consumed to batch attack multiple targets. So I think your assumption on
the attack difficulty is not correct.
> 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.
The attacker can blind the defender mempool by locating the associated
full-node with its lightning node, then broadcast a conflicting parent of
the HTLC-preimage, partitioning the mempool from the rest of the network.
The HTLC-preimage will never enter the defender's mempool, as some spent
inputs are missing.
All the considerations on network jitter, propagation delay and geographic
heterogeneity are irrelevant as network mempools are in practice a
distributed system of logically equivalent state machines to favor
propagation of high-fees paying transactions, on top of raw TCP/IP
connections. Propagation works quite deterministically on average if you
have ever used a bitcoin wallet to pay with zero-conf and see the
transaction showing up as unconfirmed on the payment processor. Policy
divergences across implementations and versions does not matter here.
The p2p stack of Bitcoin Core has some propagation delay in the order of
seconds for outbound / inbound connections transaction-relay connections. I
think they're at the advantage of the attacker, as they can be bypassed to
quickly evict the honest HTLC-timeout bypassing them with mass connections.
The p2p transaction-relay is a public network of nodes running common open
software, where their inbound slots can be occupied at low-cost and their
network address might be publicly announced. All at the advantage of the
attacker.
> 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 a 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.
As said elsewhere, I'll maintain this is a practical and critical attack on
lightning, I don't doubt you have the level of expertise in this attack by
yourself and re-think if it's a fragile one or bring new insights to the
conversation.
There are no requirements of an "extremely precise timing and execution",
the most adversarial event that an attacker might hit is a block being
mined in the order of few seconds between a HTLC-timeout hit the block
template and a block is mined. On average, you have a 10 min block interval
so probabilities are in favor of the attacker.
It is correct that miners can broadcast any of the preimage replacement
transactions, however this is not at all a deployed mechanism today by the
mining ecosystem. DoS-robustness of such a scheme is very unclear.
One more mitigation that can be done by lightning nodes today is
duplicating the mempool-monitoring mitigation to their watchtower backends,
assuming those ones are already running on top of a full-node. For each new
watchtower deployed, this is one more entity to mempool-partition by the
attacker and all of them must be well-partitioned along the attack. This
can still be neutralized by sophisticated attackers, though it's notably
raising the bar to mount a successful replacement attack.
Recommending to LN softwares to adapt this last mitigation, especially if
your implementation is used by high-value routing nodes or LSPs.
Best,
Antoine
Le sam. 21 oct. 2023 à 01:19, Olaoluwa Osuntokun <laolu32@gmail•com> a
écrit :
> > 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: 13775 bytes --]
next prev parent reply other threads:[~2023-11-17 22:36 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 16:57 [bitcoin-dev] " Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10 ` Matt Morehouse
2023-10-17 1:11 ` Antoine Riard
2023-10-20 10:47 ` Peter Todd
2023-10-20 11:18 ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17 7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34 ` ZmnSCPxj
2023-10-17 18:34 ` Antoine Riard
2023-10-20 10:31 ` Peter Todd
2023-10-20 11:03 ` Peter Todd
2023-10-20 18:35 ` Matt Morehouse
2023-10-20 21:05 ` Matt Corallo
2023-10-21 0:15 ` Peter Todd
2023-10-21 1:03 ` Matt Corallo
2023-10-21 1:25 ` Peter Todd
2023-10-21 1:55 ` Matt Corallo
2023-10-21 2:43 ` Peter Todd
2023-10-23 16:09 ` Matt Corallo
2023-10-17 17:47 ` Antoine Riard
2023-10-17 18:47 ` Antoine Riard
2023-10-18 0:17 ` Matt Corallo
2023-10-18 2:57 ` Antoine Riard
2023-10-19 8:12 ` Bastien TEINTURIER
2023-10-19 16:23 ` Matt Morehouse
2023-10-19 17:22 ` Antoine Riard
2023-10-19 17:53 ` Matt Morehouse
2023-10-19 19:33 ` Antoine Riard
2023-10-21 0:18 ` Olaoluwa Osuntokun
2023-11-17 22:36 ` Antoine Riard [this message]
2023-10-19 18:02 ` Matt Corallo
2023-10-20 6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05 ` Antoine Riard
2023-10-27 0:43 ` Peter Todd
2023-11-02 4:46 ` Antoine Riard
2023-10-21 0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21 8:58 ` David A. Harding
2023-10-21 10:31 ` Peter Todd
2023-10-22 8:30 ` vjudeu
2023-10-23 11:10 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45 ` Peter Todd
2023-11-02 5:24 ` [bitcoin-dev] " Antoine Riard
2023-11-02 6:26 ` Peter Todd
2023-11-02 17:07 ` Matt Morehouse
2023-11-03 5:27 ` Antoine Riard
2023-11-03 5:25 ` Antoine Riard
2023-11-04 7:26 ` Peter Todd
2023-11-06 18:45 ` Antoine Riard
2023-11-07 11:11 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44 ` Antoine Riard
2023-11-08 0:51 ` [bitcoin-dev] " Peter Todd
2023-11-08 2:06 ` Peter Todd
2023-11-13 2:18 ` Antoine Riard
2023-11-14 19:50 ` Peter Todd
[not found] ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53 ` [bitcoin-dev] Fwd: " Antoine Riard
2023-10-22 4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23 8:49 ` David A. Harding
2023-10-21 14:21 [bitcoin-dev] [Lightning-dev] " Nagaev Boris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALZpt+F411Qv=8znxXzv6O3r21ZdD9h24RJL2Oq6O-mdBTaYww@mail.gmail.com' \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=security@ariard$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox