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"

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"

[Nagaev Boris]

I think the presigned transactions should be interleaved fee-wise:
1.1 to Alice
1.2 to Bob
1.3 to Alice
1.4 to Bob
...

Then any such transaction evicts all previous transactions in the
chain. It reduces risks of mempool split.

If there are two transactions to Alice and to Bob both with fee 1.1,
then it is possible that half of nodes have the transaction to Alice
in their mempools and another half of nodes has the transaction to
Bob. Though I don't see how exactly this can be used in replacement
cycling attacks, I think it is safer to prevent this scenario.

On Fri Oct 20 18:35:26 UTC 2023, Matt Morehouse via bitcoin-dev wrote:
> I think if we apply this presigned fee multiplier idea to HTLC spends,
> we can prevent replacement cycles from happening.

> We could modify HTLC scripts so that *both* parties can only spend the
> HTLC via presigned second-stage transactions, and we can always sign
> those with SIGHASH_ALL.  This will prevent the attacker from adding
> inputs to their presigned transaction, so (AFAICT) a replacement
> cycling attack becomes impossible.

> The tradeoff is more bookkeeping and less fee granularity when
> claiming HTLCs on chain.


-- 
Best regards,
Boris Nagaev

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"

[Antoine Riard]

[-- 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 --]

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"

[Matt Corallo]

On 10/20/23 7:43 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
>>> Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
>>> lightning where the transaction form is deterministically derived, signing 100
>>> extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
>>> connection can transfer that in 64ms; latency will still dominate.
>>
>> Lightning today isn't all that much data, but multiply it by 100 and we
>> start racking up data enough that people may start to have to store a really
>> material amount of data for larger nodes and dealing with that starts to be
>> a much bigger pain then when we're talking about a GiB or twenty.
> 
> We are talking about storing ephemeral data here, HTLC transactions and
> possibly commitment transactions. Since lightning uses disclosed secrets to
> invalidate old state, you do not need to keep every signature from your
> counterparty indefinitely.

Mmm, fair point, yes.

>>> RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
>>> those 100 pre-signed transaction variants to do nothing more than sign every
>>> possible minimum incremental relay, you've covered a range of 1sat/vByte to
>>> 100sat/vByte. I believe that is sufficient to get mined for any block in
>>> Bitcoin's entire modern history.
>>>
>>> CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
>>> cases with very large transactions in low-fee environments, there's no
>>> circumstance where CPFP beats RBF.
>>
>> What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY
>> we can combine many HTLC claims into one transaction, vs pre-signing means
>> we're stuck with a ton of individual transactions.
> 
> Since SIGHASH_SINGLE requires one output per input, the savings you get by
> combining multiple SIGHASH_SINGLE transactions together aren't very
> significant. Just 18 bytes for nVersion, nLockTime, and the txin and txout size
> fields. The HTLC-timeout transaction is 166.5 vBytes, so that's a savings of
> just 11%

Yep, its not a lot, but for a thing that's inherently super chain-spammy, its still quite nice.

> Of course, if you _do_ need to fee bump and add an additional input, that input
> takes up space, and you'll probably need a change output. At which point you
> again would probably have been better off with a pre-signed transaction.
> 
> You are also assuming there's lots of HTLC's in flight that need to be spent.
> That's very often not the case.

In general, yes, in force-close cases often there's been some failure which is repeated in several 
HTLCs :).

More generally, I think we're getting lost here - this isn't really a material change for 
lightning's trust model - its already the case that a peer that is willing to put a lot of work in 
can probably steal your money, and there's now just one more way they can do that. We really don't 
need to rush to "fix lightning" here, we can do it right and fix it at the ecosystem level. It 
shouldn't be the case that a policy restriction results in both screwing up a L2 network *and* 
results in miners getting paid less. That's a policy bug.

Matt

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"

[Peter Todd]

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

On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
> > Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
> > lightning where the transaction form is deterministically derived, signing 100
> > extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
> > connection can transfer that in 64ms; latency will still dominate.
> 
> Lightning today isn't all that much data, but multiply it by 100 and we
> start racking up data enough that people may start to have to store a really
> material amount of data for larger nodes and dealing with that starts to be
> a much bigger pain then when we're talking about a GiB or twenty.

We are talking about storing ephemeral data here, HTLC transactions and
possibly commitment transactions. Since lightning uses disclosed secrets to
invalidate old state, you do not need to keep every signature from your
counterparty indefinitely.

Per channel, with the above numbers, you'd need <10KB worth of extra signatures
to fee bump the current commitment (with pre-signed txs), and if HTLCs happen
to be in flight, say <10KB of extra signatures per HTLC.

Amazon AWS charges $0.125/GB/month for their most expensive SSD volumes. Let's
round that up to $1/GB/month to account for RAID and backups. Let's say each
channel constantly has 483 HTLC's in flight, and each HTLC is associated with
~10KB of extra data for pre-signed transactions.

That's ~5MB/channel of data you constantly need to store, or $0.005/month.

In what world is that too expensive or too much of a pain to deal with? If
you're node is actually that busy, you're probably making that cost back per
channel every minute, or better.

> > RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
> > those 100 pre-signed transaction variants to do nothing more than sign every
> > possible minimum incremental relay, you've covered a range of 1sat/vByte to
> > 100sat/vByte. I believe that is sufficient to get mined for any block in
> > Bitcoin's entire modern history.
> > 
> > CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
> > cases with very large transactions in low-fee environments, there's no
> > circumstance where CPFP beats RBF.
> 
> What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY
> we can combine many HTLC claims into one transaction, vs pre-signing means
> we're stuck with a ton of individual transactions.

Since SIGHASH_SINGLE requires one output per input, the savings you get by
combining multiple SIGHASH_SINGLE transactions together aren't very
significant. Just 18 bytes for nVersion, nLockTime, and the txin and txout size
fields. The HTLC-timeout transaction is 166.5 vBytes, so that's a savings of
just 11%

Of course, if you _do_ need to fee bump and add an additional input, that input
takes up space, and you'll probably need a change output. At which point you
again would probably have been better off with a pre-signed transaction.

You are also assuming there's lots of HTLC's in flight that need to be spent.
That's very often not the case.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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"

[Matt Corallo]

On 10/20/23 9:25 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
>>> What are anchor outputs used for other than increasing fees?
>>>
>>> Because if we've pre-signed the full fee range, there is simply no need for
>>> anchor outputs. Under any circumstance we can broadcast a transaction with a
>>> sufficiently high fee to get mined.
>>
>>
>> Indeed, that is what anchor outputs are for. Removing the pre-set feerate
>> solved a number of issues with edge-cases and helped address the
>> fee-inflation attack. Now, just using pre-signed transactions doesn't have
>> to re-introduce those issues - as long as the broadcaster gets to pick which
>> of the possible transactions they broadcast its just another transaction of
>> theirs.
>>
>> Still, I'm generally really dubious of the multiple pre-signed transaction
>> thing, (a) it would mean more fee overhead (not the end of the world for a
>> force-closure, but it sucks to have all these individual transactions
>> rolling around and be unable to batch), but more importantly (b) its a bunch
>> of overhead to keep track of a ton of variants across a sufficiently
>> granular set of feerates for it to not result in substantially overspending
>> on fees.
> 
> Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
> lightning where the transaction form is deterministically derived, signing 100
> extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
> connection can transfer that in 64ms; latency will still dominate.

Lightning today isn't all that much data, but multiply it by 100 and we start racking up data enough 
that people may start to have to store a really material amount of data for larger nodes and dealing 
with that starts to be a much bigger pain then when we're talking about a GiB or twenty.

> RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
> those 100 pre-signed transaction variants to do nothing more than sign every
> possible minimum incremental relay, you've covered a range of 1sat/vByte to
> 100sat/vByte. I believe that is sufficient to get mined for any block in
> Bitcoin's entire modern history.
> 
> CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
> cases with very large transactions in low-fee environments, there's no
> circumstance where CPFP beats RBF.

What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY we can combine many HTLC 
claims into one transaction, vs pre-signing means we're stuck with a ton of individual transactions.

Matt

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"

[Peter Todd]

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

On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
> > What are anchor outputs used for other than increasing fees?
> > 
> > Because if we've pre-signed the full fee range, there is simply no need for
> > anchor outputs. Under any circumstance we can broadcast a transaction with a
> > sufficiently high fee to get mined.
> 
> 
> Indeed, that is what anchor outputs are for. Removing the pre-set feerate
> solved a number of issues with edge-cases and helped address the
> fee-inflation attack. Now, just using pre-signed transactions doesn't have
> to re-introduce those issues - as long as the broadcaster gets to pick which
> of the possible transactions they broadcast its just another transaction of
> theirs.
> 
> Still, I'm generally really dubious of the multiple pre-signed transaction
> thing, (a) it would mean more fee overhead (not the end of the world for a
> force-closure, but it sucks to have all these individual transactions
> rolling around and be unable to batch), but more importantly (b) its a bunch
> of overhead to keep track of a ton of variants across a sufficiently
> granular set of feerates for it to not result in substantially overspending
> on fees.

Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
lightning where the transaction form is deterministically derived, signing 100
extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
connection can transfer that in 64ms; latency will still dominate.

RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
those 100 pre-signed transaction variants to do nothing more than sign every
possible minimum incremental relay, you've covered a range of 1sat/vByte to
100sat/vByte. I believe that is sufficient to get mined for any block in
Bitcoin's entire modern history.

CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
cases with very large transactions in low-fee environments, there's no
circumstance where CPFP beats RBF.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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"

[Matt Corallo]

On 10/20/23 8:15 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
>> Sadly this only is really viable for pre-anchor channels. With anchor
>> channels the attack can be performed by either side of the closure, as the
>> HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you
>> to add more inputs and perform this attack even as the broadcaster.
>>
>> I don't think its really viable to walk that change back to fix this, as it
>> also fixed plenty of other issues with channel usability and important
>> edge-cases.
> 
> What are anchor outputs used for other than increasing fees?
> 
> Because if we've pre-signed the full fee range, there is simply no need for
> anchor outputs. Under any circumstance we can broadcast a transaction with a
> sufficiently high fee to get mined.


Indeed, that is what anchor outputs are for. Removing the pre-set feerate solved a number of issues 
with edge-cases and helped address the fee-inflation attack. Now, just using pre-signed transactions 
doesn't have to re-introduce those issues - as long as the broadcaster gets to pick which of the 
possible transactions they broadcast its just another transaction of theirs.

Still, I'm generally really dubious of the multiple pre-signed transaction thing, (a) it would mean 
more fee overhead (not the end of the world for a force-closure, but it sucks to have all these 
individual transactions rolling around and be unable to batch), but more importantly (b) its a bunch 
of overhead to keep track of a ton of variants across a sufficiently granular set of feerates for it 
to not result in substantially overspending on fees.

Like I mentioned in the previous mail, this is really a policy bug - we're talking about a 
transaction pattern that might well happen where miners aren't getting the optimal value in 
transaction fees (potentially by a good bit). This needs to be fixed at the policy/Bitcoin Core 
layer, not in the lightning world (as much as its pretty resource-intensive to fix in the policy 
domain, I think).

Matt

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"

[Olaoluwa Osuntokun]

[-- 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 --]

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"

[Peter Todd]

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

On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
> Sadly this only is really viable for pre-anchor channels. With anchor
> channels the attack can be performed by either side of the closure, as the
> HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you
> to add more inputs and perform this attack even as the broadcaster.
> 
> I don't think its really viable to walk that change back to fix this, as it
> also fixed plenty of other issues with channel usability and important
> edge-cases.

What are anchor outputs used for other than increasing fees?

Because if we've pre-signed the full fee range, there is simply no need for
anchor outputs. Under any circumstance we can broadcast a transaction with a
sufficiently high fee to get mined.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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"

[Matt Corallo]

Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be 
performed by either side of the closure, as the HTLCs are now, at max, only signed 
SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the 
broadcaster.

I don't think its really viable to walk that change back to fix this, as it also fixed plenty of 
other issues with channel usability and important edge-cases.

I'll highlight that fixing this issue on the lightning end isn't really the right approach generally 
- we're talking about a case where a lightning counterparty engineered a transaction broadcast 
ordering such that miners are *not* including the optimal set of transactions for fee revenue. Given 
such a scenario exists (and its not unrealistic to think someone might wish to engineer such a 
situation), the fix ultimately needs to lie with Bitcoin Core (or other parts of the mining stack).

Now, fixing this in the Bitcoin Core stack is no trivial deal - the reason for this attack is to 
keep enough history to fix it Bitcoin Core would need unbounded memory. However, its not hard to 
imagine a simple external piece of software which monitors the mempool for transactions which were 
replaced out but which may be able to re-enter the mempool later with other replacements and store 
them on disk. From there, this software could optimize the revenue of block template selection, 
while also accidentally fixing this issue.

Matt

On 10/20/23 2:35 PM, Matt Morehouse via bitcoin-dev wrote:
> I think if we apply this presigned fee multiplier idea to HTLC spends,
> we can prevent replacement cycles from happening.
> 
> We could modify HTLC scripts so that *both* parties can only spend the
> HTLC via presigned second-stage transactions, and we can always sign
> those with SIGHASH_ALL.  This will prevent the attacker from adding
> inputs to their presigned transaction, so (AFAICT) a replacement
> cycling attack becomes impossible.
> 
> The tradeoff is more bookkeeping and less fee granularity when
> claiming HTLCs on chain.
> 
> On Fri, Oct 20, 2023 at 11:04 AM Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote:
>>> As I have suggested before, the correct way to do pre-signed transactions is to
>>> pre-sign enough *different* transactions to cover all reasonable needs for
>>> bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
>>> different replacement transactions covers a fee range of 1024x. And you
>>> obviously can improve on this by increasing the multiplier towards the end of
>>> the range.
>>
>> To be clear, when I say "increasing the multiplier", I mean, starting with a
>> smaller multiplier at the beginning of the range, and ending with a bigger one.
>>
>> Eg feebumping with fee increases pre-signed for something like:
>>
>>      1.1
>>      1.2
>>      1.4
>>      1.8
>>      2.6
>>      4.2
>>      7.4
>>
>> etc.
>>
>> That would use most of the range for smaller bumps, as a %, with larger % bumps
>> reserved for the end where our strategy is changing to something more
>> "scorched-earth"
>>
>> And of course, applying this idea properly to commitment transactions will mean
>> that the replacements may have HTLCs removed, when their value drops below the
>> fees necessary to get those outputs mined.
>>
>> Note too that we can sign simultaneous variants of transactions that deduct the
>> fees from different party's outputs. Eg Alice can give Bob the ability to
>> broadcast higher and higher fee txs, taking the fees from Bob's output(s), and
>> Bob can give Alice the same ability, taking the fees from Alice's output(s). I
>> haven't thought through how this would work with musig. But you can certainly
>> do that with plain old OP_CheckMultisig.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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"

[Matt Morehouse]

I think if we apply this presigned fee multiplier idea to HTLC spends,
we can prevent replacement cycles from happening.

We could modify HTLC scripts so that *both* parties can only spend the
HTLC via presigned second-stage transactions, and we can always sign
those with SIGHASH_ALL.  This will prevent the attacker from adding
inputs to their presigned transaction, so (AFAICT) a replacement
cycling attack becomes impossible.

The tradeoff is more bookkeeping and less fee granularity when
claiming HTLCs on chain.

On Fri, Oct 20, 2023 at 11:04 AM Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote:
> > As I have suggested before, the correct way to do pre-signed transactions is to
> > pre-sign enough *different* transactions to cover all reasonable needs for
> > bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
> > different replacement transactions covers a fee range of 1024x. And you
> > obviously can improve on this by increasing the multiplier towards the end of
> > the range.
>
> To be clear, when I say "increasing the multiplier", I mean, starting with a
> smaller multiplier at the beginning of the range, and ending with a bigger one.
>
> Eg feebumping with fee increases pre-signed for something like:
>
>     1.1
>     1.2
>     1.4
>     1.8
>     2.6
>     4.2
>     7.4
>
> etc.
>
> That would use most of the range for smaller bumps, as a %, with larger % bumps
> reserved for the end where our strategy is changing to something more
> "scorched-earth"
>
> And of course, applying this idea properly to commitment transactions will mean
> that the replacements may have HTLCs removed, when their value drops below the
> fees necessary to get those outputs mined.
>
> Note too that we can sign simultaneous variants of transactions that deduct the
> fees from different party's outputs. Eg Alice can give Bob the ability to
> broadcast higher and higher fee txs, taking the fees from Bob's output(s), and
> Bob can give Alice the same ability, taking the fees from Alice's output(s). I
> haven't thought through how this would work with musig. But you can certainly
> do that with plain old OP_CheckMultisig.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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"

[Peter Todd]

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

On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote:
> As I have suggested before, the correct way to do pre-signed transactions is to
> pre-sign enough *different* transactions to cover all reasonable needs for
> bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
> different replacement transactions covers a fee range of 1024x. And you
> obviously can improve on this by increasing the multiplier towards the end of
> the range.

To be clear, when I say "increasing the multiplier", I mean, starting with a
smaller multiplier at the beginning of the range, and ending with a bigger one.

Eg feebumping with fee increases pre-signed for something like:

    1.1
    1.2
    1.4
    1.8
    2.6
    4.2
    7.4

etc.

That would use most of the range for smaller bumps, as a %, with larger % bumps
reserved for the end where our strategy is changing to something more
"scorched-earth"

And of course, applying this idea properly to commitment transactions will mean
that the replacements may have HTLCs removed, when their value drops below the
fees necessary to get those outputs mined.

Note too that we can sign simultaneous variants of transactions that deduct the
fees from different party's outputs. Eg Alice can give Bob the ability to
broadcast higher and higher fee txs, taking the fees from Bob's output(s), and
Bob can give Alice the same ability, taking the fees from Alice's output(s). I
haven't thought through how this would work with musig. But you can certainly
do that with plain old OP_CheckMultisig.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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"

[Peter Todd]

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

On Tue, Oct 17, 2023 at 10:34:04AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Antoine et al.,
> 
> Let me try to rephrase the core of the attack.
> 
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==` are channels):
> 
>     A ===== B ===== C
> 
> `A` routes `A->B->C`.
> 
> The timelocks, for example, could be:
> 
>    A->B timeelock = 144
>    B->C timelock = 100
> 
> The above satisfies the LN BOLT requirements, as long as `B` has a `cltv_expiry_delta` of 44 or lower.
> 
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the signed transactions --- commitment transaction and HTLC-timeout transactions --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and HTLC-timeout transaction do not confirm.

The problem here is we're failing to use RBF.

As I have suggested before, the correct way to do pre-signed transactions is to
pre-sign enough *different* transactions to cover all reasonable needs for
bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
different replacement transactions covers a fee range of 1024x. And you
obviously can improve on this by increasing the multiplier towards the end of
the range.

Increasing per-tx (temporary) storage and bandwidth costs by ~10x or even ~100x
is not a big deal in the context of a highly scalable protocol like Lightning.

There is zero reason why the B->C transactions should be getting stuck. This is
a major failing of the Lightning protocol that should be fixed. And of course,
this fix should be applied to other aspects of the lightning protocol, such as
channel opens, etc.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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"

[Antoine Riard]

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

> As the CLTV
> delta deadline approaches, the fees in case 2 may be 50%, 80%, even
> 100% of the HTLC value under such a scorched earth policy.

A replacement-cycling attacker can afford to pay 100% of the HTLC value
under the defender scorched earth policy and still realize an economic gain.

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.

Under this defensive fee scorched earth policy, Alice broadcasts her
HTLC-timeout at T + 1 with 10 000 sats committed as absolute fee.

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.
HTLC-preimage Y conflicts with HTLC-preimage X too (here comes the
multiplied by 2 of the rbf penalty).

Caroll broadcasts her HTLC-timeout of 200 000 sats at T+5. It is replaced
by Mallory at T+6 with her HTLC-preimage Z of 200 000 sats (+rbf penalty 1
sat / vb rule 4 * 3). Caroll's HTLC-timeout is out of network mempools.
HTLC-preimage Z conflicts with HTLC-preimage Z too (here comes the
multiplied by 3 of rbf penalty).

At any time if Mallory's HTLC-preimage enters into the top mempool feerates
group (due to the accumulated rbf penalty), one unconfirmed ancestor can be
double-spent to evict out the HTLC-preimage.

If Mallory succeeds the replacement cycling, she might be at loss of 10 000
sats + rbf penalty cost for each rebroadcast attempt of the victim. However
she wins Alice + Bob + Carol HTLC value of 200 000 sats each.

Assuming 5 rebroadcasts per block (even on random timers) multiplied by 3
victims, 200 bytes of HTLC-preimage and cltv_delta of 144 blocks, the total
attacker cost is 432 000 sats.

The economic gain realized is 168 000 sats. Sounds each additional victim
has a cost of 144 000 sats, whatever the HTLC value targeted.

Thanks for checking the fees math and replacement rules, though it sounds
correct to me.

(And here without introducing more favorable assumptions to the attacker,
like mempool spikes where the "honest" HTLC-timeout transactions can be let
floating in network mempools).

Best,
Antoine

Le jeu. 19 oct. 2023 à 18:54, Matt Morehouse <mattmorehouse@gmail.com> a
écrit :

> On Thu, Oct 19, 2023 at 5:22 PM Antoine Riard <antoine.riard@gmail.com>
> wrote:
> >
> > Hi Matt,
> >
> > This mitigation is mentioned in the attached paper (see subsection 3.4
> defensive fee-rebroadcasting)
> >
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
> >
> > As soon as you start to have a bit of a mempool backlog and the
> defensive fractional fee HTLC-timeout stays stuck, it gives the advantage
> to the attacker again.
> >
> > Beyond that, I think an attacker can replace-cycle multiple honest
> HTLC-timeout with a single malicious HTLC-preimage (with a sequence of
> replacement, not concurrently) paying the absolute fee, while only
> encumbering the RBF penalty. I didn't test this specific behavior, though
> the "fees" math doesn't seem at the advantage of the defenders at first
> sight.
>
> Right, some replacement cycles can be avoided by the attacker to
> reduce the cost of the attack.  But with the defender implementing a
> scorched-earth fee bumping policy, eventually either (1) the
> HTLC-timeout *will* confirm in the next block or (2) the attacker must
> pay more fees than the HTLC-timeout fees to replace it.  As the CLTV
> delta deadline approaches, the fees in case 2 may be 50%, 80%, even
> 100% of the HTLC value under such a scorched earth policy.  So even if
> the attacker only has to do one replacement cycle right before the
> deadline, the attack can be made unprofitable.  And in practice, with
> HTLC values significantly greater than the next-block fee cost, the
> attacker will need to do multiple replacements as the deadline
> approaches.
>
> And of course this linear scorched earth policy is just an
> illustration.  We should further tune the fee bumping curve across the
> full CLTV delta to ensure minimal fees paid when not under attack.
> But as we approach the deadline, it makes sense to become very
> aggressive both to get our transaction confirmed during high mempool
> congestion and to punish replacement-cycling attackers.
>
> >
> > Best,
> > Antoine
> >
> > Le jeu. 19 oct. 2023 à 17:23, Matt Morehouse <mattmorehouse@gmail.com>
> a écrit :
> >>
> >> On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> > 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
> node 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
> Bitcoin node on the same IP
> >> > address, making it very clear what the "local node" of the lightning
> node 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.
> >>
> >> What if the honest node aggressively fee-bumps and retransmits the
> >> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
> >> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
> >> increasing the fee by 1/10th the HTLC value for each non-confirmation.
> >>
> >> This "scorched earth" approach may cost the honest node considerable
> >> fees, but it will cost the attacker even more, since each attacker
> >> replacement needs to burn at least as much as the HTLC-timeout fees,
> >> and the attacker will need to do a replacement every time the honest
> >> node fee bumps.
> >>
> >> I think this fee-bumping policy will provide sufficient defense even
> >> if the attacker is replacement-cycling directly in miners' mempools
> >> and the victim has no visibility into the attack.
> >>
> >> >
> >> > 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, by 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
> history 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 to 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-paper/replacement-cycling.pdf
> >> > > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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
> hop 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
> feerate 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 at 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
> timelock 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
> benefits from the HTLC-timeout being
> >> > > usually broadcast by lightning nodes only once every block, or less
> the 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
> how 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 to 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=3 policy). Ideally, they should
> constraint a pinning attacker to
> >> > > always attach a high feerate package (commitment + CPFP) to replace
> the 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=3 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=3 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
> transactions is made more widely known,
> >> > > the carve-out exemption in mempool rules to mitigate in-mempool
> package 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
> finding 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
> cycling 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,
> and 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
> the 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
>

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

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"

[Matt Corallo]

That certainly helps, yes, and I think many nodes do something akin to this already, but I'm not 
sure we can say that the problem has been fixed if the victim has to spend way more than the 
prevailing mempool fees (and potentially burn a large % of their HTLC value) :).

Matt

On 10/19/23 12:23 PM, Matt Morehouse wrote:
> On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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 node 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 Bitcoin node on the same IP
>> address, making it very clear what the "local node" of the lightning node 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.
> 
> What if the honest node aggressively fee-bumps and retransmits the
> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
> increasing the fee by 1/10th the HTLC value for each non-confirmation.
> 
> This "scorched earth" approach may cost the honest node considerable
> fees, but it will cost the attacker even more, since each attacker
> replacement needs to burn at least as much as the HTLC-timeout fees,
> and the attacker will need to do a replacement every time the honest
> node fee bumps.
> 
> I think this fee-bumping policy will provide sufficient defense even
> if the attacker is replacement-cycling directly in miners' mempools
> and the victim has no visibility into the attack.
> 
>>
>> 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, by 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 history 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 to 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-paper/replacement-cycling.pdf
>>> <https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop 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 feerate 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 at 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 timelock 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 benefits from the HTLC-timeout being
>>> usually broadcast by lightning nodes only once every block, or less the 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 how 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 to 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=3 policy). Ideally, they should constraint a pinning attacker to
>>> always attach a high feerate package (commitment + CPFP) to replace the 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=3 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=3 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 transactions is made more widely known,
>>> the carve-out exemption in mempool rules to mitigate in-mempool package 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 finding 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 cycling 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, and 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 the 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

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"

[Matt Morehouse]

On Thu, Oct 19, 2023 at 5:22 PM Antoine Riard <antoine.riard@gmail.com> wrote:
>
> Hi Matt,
>
> This mitigation is mentioned in the attached paper (see subsection 3.4 defensive fee-rebroadcasting)
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
> As soon as you start to have a bit of a mempool backlog and the defensive fractional fee HTLC-timeout stays stuck, it gives the advantage to the attacker again.
>
> Beyond that, I think an attacker can replace-cycle multiple honest HTLC-timeout with a single malicious HTLC-preimage (with a sequence of replacement, not concurrently) paying the absolute fee, while only encumbering the RBF penalty. I didn't test this specific behavior, though the "fees" math doesn't seem at the advantage of the defenders at first sight.

Right, some replacement cycles can be avoided by the attacker to
reduce the cost of the attack.  But with the defender implementing a
scorched-earth fee bumping policy, eventually either (1) the
HTLC-timeout *will* confirm in the next block or (2) the attacker must
pay more fees than the HTLC-timeout fees to replace it.  As the CLTV
delta deadline approaches, the fees in case 2 may be 50%, 80%, even
100% of the HTLC value under such a scorched earth policy.  So even if
the attacker only has to do one replacement cycle right before the
deadline, the attack can be made unprofitable.  And in practice, with
HTLC values significantly greater than the next-block fee cost, the
attacker will need to do multiple replacements as the deadline
approaches.

And of course this linear scorched earth policy is just an
illustration.  We should further tune the fee bumping curve across the
full CLTV delta to ensure minimal fees paid when not under attack.
But as we approach the deadline, it makes sense to become very
aggressive both to get our transaction confirmed during high mempool
congestion and to punish replacement-cycling attackers.

>
> Best,
> Antoine
>
> Le jeu. 19 oct. 2023 à 17:23, Matt Morehouse <mattmorehouse@gmail.com> a écrit :
>>
>> On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > 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 node 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 Bitcoin node on the same IP
>> > address, making it very clear what the "local node" of the lightning node 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.
>>
>> What if the honest node aggressively fee-bumps and retransmits the
>> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
>> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
>> increasing the fee by 1/10th the HTLC value for each non-confirmation.
>>
>> This "scorched earth" approach may cost the honest node considerable
>> fees, but it will cost the attacker even more, since each attacker
>> replacement needs to burn at least as much as the HTLC-timeout fees,
>> and the attacker will need to do a replacement every time the honest
>> node fee bumps.
>>
>> I think this fee-bumping policy will provide sufficient defense even
>> if the attacker is replacement-cycling directly in miners' mempools
>> and the victim has no visibility into the attack.
>>
>> >
>> > 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, by 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 history 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 to 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-paper/replacement-cycling.pdf
>> > > <https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop 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 feerate 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 at 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 timelock 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 benefits from the HTLC-timeout being
>> > > usually broadcast by lightning nodes only once every block, or less the 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 how 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 to 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=3 policy). Ideally, they should constraint a pinning attacker to
>> > > always attach a high feerate package (commitment + CPFP) to replace the 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=3 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=3 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 transactions is made more widely known,
>> > > the carve-out exemption in mempool rules to mitigate in-mempool package 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 finding 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 cycling 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, and 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 the 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

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"

[Antoine Riard]

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

Hi Matt,

This mitigation is mentioned in the attached paper (see subsection 3.4
defensive fee-rebroadcasting)
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf

As soon as you start to have a bit of a mempool backlog and the defensive
fractional fee HTLC-timeout stays stuck, it gives the advantage to the
attacker again.

Beyond that, I think an attacker can replace-cycle multiple honest
HTLC-timeout with a single malicious HTLC-preimage (with a sequence of
replacement, not concurrently) paying the absolute fee, while only
encumbering the RBF penalty. I didn't test this specific behavior, though
the "fees" math doesn't seem at the advantage of the defenders at first
sight.

Best,
Antoine

Le jeu. 19 oct. 2023 à 17:23, Matt Morehouse <mattmorehouse@gmail.com> a
écrit :

> On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > 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
> node 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
> Bitcoin node on the same IP
> > address, making it very clear what the "local node" of the lightning
> node 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.
>
> What if the honest node aggressively fee-bumps and retransmits the
> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
> increasing the fee by 1/10th the HTLC value for each non-confirmation.
>
> This "scorched earth" approach may cost the honest node considerable
> fees, but it will cost the attacker even more, since each attacker
> replacement needs to burn at least as much as the HTLC-timeout fees,
> and the attacker will need to do a replacement every time the honest
> node fee bumps.
>
> I think this fee-bumping policy will provide sufficient defense even
> if the attacker is replacement-cycling directly in miners' mempools
> and the victim has no visibility into the attack.
>
> >
> > 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,
> by 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
> history 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
> to 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-paper/replacement-cycling.pdf
> > > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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
> hop 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
> feerate 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
> at 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
> timelock 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
> benefits from the HTLC-timeout being
> > > usually broadcast by lightning nodes only once every block, or less
> the 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
> how 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
> to 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=3 policy). Ideally, they should
> constraint a pinning attacker to
> > > always attach a high feerate package (commitment + CPFP) to replace
> the 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=3 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=3 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
> transactions is made more widely known,
> > > the carve-out exemption in mempool rules to mitigate in-mempool
> package 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
> finding 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
> cycling 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,
> and 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
> the 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
>

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

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"

[Matt Morehouse]

On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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 node 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 Bitcoin node on the same IP
> address, making it very clear what the "local node" of the lightning node 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.

What if the honest node aggressively fee-bumps and retransmits the
HTLC-timeout as the CLTV delta deadline approaches, as suggested by
Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
increasing the fee by 1/10th the HTLC value for each non-confirmation.

This "scorched earth" approach may cost the honest node considerable
fees, but it will cost the attacker even more, since each attacker
replacement needs to burn at least as much as the HTLC-timeout fees,
and the attacker will need to do a replacement every time the honest
node fee bumps.

I think this fee-bumping policy will provide sufficient defense even
if the attacker is replacement-cycling directly in miners' mempools
and the victim has no visibility into the attack.

>
> 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, by 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 history 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 to 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-paper/replacement-cycling.pdf
> > <https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop 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 feerate 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 at 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 timelock 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 benefits from the HTLC-timeout being
> > usually broadcast by lightning nodes only once every block, or less the 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 how 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 to 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=3 policy). Ideally, they should constraint a pinning attacker to
> > always attach a high feerate package (commitment + CPFP) to replace the 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=3 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=3 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 transactions is made more widely known,
> > the carve-out exemption in mempool rules to mitigate in-mempool package 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 finding 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 cycling 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, and 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 the 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

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"

[Bastien TEINTURIER]

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

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 à 11:07, Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> 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 their
> own block templates, and therefore the number of miners' mempools where an
> attacker has to successfully continuously replace in cycles channels
> counterparties transactions.
>
> A replacement buffer or history of transactions at the mempool level might
> be a mitigation to this attack. I believe this is yet to be seen if it can
> 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 à 01:17, Matt Corallo <lf-lists@mattcorallo.com> a
> écrit :
>
>> 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 node
>> 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 Bitcoin
>> node on the same IP
>> address, making it very clear what the "local node" of the lightning node
>> 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, by
>> 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 history
>> 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 to
>> 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-paper/replacement-cycling.pdf
>> > <
>> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop
>> 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 feerate
>> 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 at
>> 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 timelock
>> 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 benefits
>> from the HTLC-timeout being
>> > usually broadcast by lightning nodes only once every block, or less the
>> 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 how
>> 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 to
>> 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=3 policy). Ideally, they should
>> constraint a pinning attacker to
>> > always attach a high feerate package (commitment + CPFP) to replace the
>> 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=3 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=3 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 transactions
>> is made more widely known,
>> > the carve-out exemption in mempool rules to mitigate in-mempool package
>> 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 finding
>> 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 cycling
>> 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, and
>> 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 the
>> 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
>

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

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"

[Antoine Riard]

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

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 their
own block templates, and therefore the number of miners' mempools where an
attacker has to successfully continuously replace in cycles channels
counterparties transactions.

A replacement buffer or history of transactions at the mempool level might
be a mitigation to this attack. I believe this is yet to be seen if it can
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 à 01:17, Matt Corallo <lf-lists@mattcorallo.com> a
écrit :

> 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 node
> 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 Bitcoin
> node on the same IP
> address, making it very clear what the "local node" of the lightning node
> 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, by
> 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 history
> 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 to
> 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-paper/replacement-cycling.pdf
> > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop
> 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 feerate
> 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 at
> 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 timelock
> 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 benefits
> from the HTLC-timeout being
> > usually broadcast by lightning nodes only once every block, or less the
> 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 how
> 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 to
> 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=3 policy). Ideally, they should
> constraint a pinning attacker to
> > always attach a high feerate package (commitment + CPFP) to replace the
> 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=3 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=3 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 transactions
> is made more widely known,
> > the carve-out exemption in mempool rules to mitigate in-mempool package
> 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 finding
> 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 cycling
> 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, and
> 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 the
> same" - K.
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

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"

[Matt Corallo]

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 node 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 Bitcoin node on the same IP 
address, making it very clear what the "local node" of the lightning node 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, by 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 history 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 to 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-paper/replacement-cycling.pdf 
> <https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/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 hop 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 feerate 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 at 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 timelock 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 benefits from the HTLC-timeout being 
> usually broadcast by lightning nodes only once every block, or less the 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 how 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 to 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=3 policy). Ideally, they should constraint a pinning attacker to 
> always attach a high feerate package (commitment + CPFP) to replace the 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=3 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=3 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 transactions is made more widely known, 
> the carve-out exemption in mempool rules to mitigate in-mempool package 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 finding 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 cycling 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, and 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 the same" - K.
> 
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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"

[Antoine Riard]

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

> We have conducted one so far, multiple scenarios to look at.

_*none*_ so far. typo of mine - apologize english is not my native language.

We discussed conducting experiments pre-disclosure in an e-mail of the 11th
August 2023.

"If someone is down to setup a "black box" Lightning infra on mainet, I'm
game on to exercise the vulnerabilities and mitigations during the coming
months and revisit the disclosure date dependent on the learnings."

However as the number of Lightning worldwide experts who have level of
knowledge and understandings to take part to experiments is I think
restrained to people listed on the disclosure mails _and_ we had other
pendings non-disclosed security issues at the time like the ones revealed
"fake channel DoS vector" the 23th August 2023, we didn't conduct them.

Le mar. 17 oct. 2023 à 18:47, Antoine Riard <antoine.riard@gmail.com> a
écrit :

> Hi Ziggie,
>
> > thanks for this detailed explanation. This class of pinning attacks
> sound not too unlikely especially if the attacker targets channels with
> high capacity and very loose channel policies (allowing the full htlc
> > amount to be the channel capacity). Could you add more details about the
> attack you observed on mainnet ? How did you monitor the chain, are the
> some tools available I can run in parallel to my
> > lightning software to record this kind of suspicious behaviour (which
> did you use)?
>
> Just to give a clarification no _such_ attack has been observed on
> mainnet, since I and other LN maintainers have been aware of this issue. If
> there is a confusion on the disclosure mail thanks to point to it, I'll
> correct it.
>
> We discussed privately to experiment a demo attack in restrained dev
> circles, like we have done in the past for some LN sec issues. We have
> conducted one so far, multiple scenarios to look at.
>
> I confirm the risk of exposure if an attacker targets channels with high
> capacity and loose channel policies. Note there is no way to configure the
> cap for the total value of outbound HTLC in-flight, which is the flow
> affected.
>
> If you would like to observe the existence of such an attack happening,
> look at your mempool logs and the amount of HTLC output being
> systematically conflicted out with the following sequence (HTLC-timeout -
> HTLC-preimage - HTLC-timeout - ...).
>
> As an observation note, this is not akin to a pinning attack, as there is
> no "honest" or "malicious" transaction pinned in network mempools. And it
> can happen without network mempools congestion.
>
> > What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc- timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> I think this is a behavior worthy of testing.
>
> > Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think
> > currently when lightning nodes see the preimage in the mempool (during
> the time where they already can spend the same output with the
> timeout-covenant) we are honest and just extract
> > the preimage and don't try to race this tx output.
>
> Local-mempool preimage monitoring has been implemented by Eclair for years
> as a mitigation against old school pinning attacks on second-stage HTLC
> transactions.
>
> This mechanism has been implemented by LND in the last months, following
> the report of replacement cycling attacks. As of today this is not
> implemented by Core-Lightning or LDK.
>
> > So we maybe should start feebumping this output if we end up in this
> scenario? If we see the preimage and can also claim this output via the
> htlc-timeout path, we should aggressively fee-bump (racing this output) our
> htlc-output in addition to grabbing the preimage and claiming it on the
> incoming. This is only feasible with anchor channels where we can add fees
> to the htlc-covenant. This would make the attack more costly for a peer
> when he knows that we use fees up to 50% of the htlc value. When you cycle
> this 144 times you will be at a heavy loss trying to steal this htlc.
>
> This is the "defensive fee mitigation" proposed in the paper. Coming with
> some unknown.
>
> > I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs  for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
> See the point above on the lack of way at the spec-level to negotiate cap
> on the total value of outbound HTLC in-flight.
>
> Le mar. 17 oct. 2023 à 08:21, ziggie1984 <ziggie1984@protonmail.com> a
> écrit :
>
>> ## Deployed LN mitigations
>>
>> Aggressive rebroadcasting: As the replacement cycling attacker benefits
>> from the HTLC-timeout being usually broadcast by lightning nodes only once
>> every block, or less the 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.
>>
>>
>> Hi Antoine,
>>
>> thanks for this detailed explanation. This class of pinning attacks sound
>> not too unlikely especially if the attacker targets channels with high
>> capacity and very loose channel policies (allowing the full htlc amount to
>> be the channel capacity). Could you add more details about the attack you
>> observed on mainnet ? How did you monitor the chain, are the some tools
>> available I can run in parallel to my lightning software to record this
>> kind of suspicious behaviour (which did you use)?
>> What's also worth mentioning here is that you do not really have to
>> control 2 neighbouring nodes to target your victim. If you can cycle the
>> attack on the tail side and delay the confirmation of the htlc-timeout
>> covenant the peer at the front (incoming link) of the victim will
>> force-close the channel and claim his timeout-path in the same way
>> (canceling back the initial htlc amount to the attackers initial node).
>>
>> Apart from that I think one can even introduce some kind of feebumping
>> race between the victim and the attacker on the tail side of the attack
>> making the attack even more costly. I think currently when lightning nodes
>> see the preimage in the mempool (during the time where they already can
>> spend the same output with the timeout-covenant) we are honest and just
>> extract the preimage and don't try to race this tx output. So we maybe
>> should start feebumping this output if we end up in this scenario? If we
>> see the preimage and can also claim this output via the htlc-timeout path,
>> we should aggressively fee-bump (racing this output) our htlc-output in
>> addition to grabbing the preimage and claiming it on the incoming. This is
>> only feasible with anchor channels where we can add fees to the
>> htlc-covenant. This would make the attack more costly for a peer when he
>> knows that we use fees up to 50% of the htlc value. When you cycle this 144
>> times you will be at a heavy loss trying to steal this htlc.
>>
>> I would add another mitigation to the list for node runners to restrict
>> the amount and number of HTLCs  for big channels to unknown peers. It
>> quickly comes with a loss when the HTLCs the attacker tries to steal are
>> small.
>>
>>
>> Kind regards,
>>
>> ziggie
>>
>>
>> ------- Original Message -------
>> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
>> antoine.riard@gmail.com> wrote:
>>
>> (cross-posting mempool issues identified are exposing lightning chan to
>> 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-paper/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 hop
>> 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 feerate 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 at 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 timelock 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
>>
>> ## Deployed LN mitigations
>>
>> Aggressive rebroadcasting: As the replacement cycling attacker benefits
>> from the HTLC-timeout being usually broadcast by lightning nodes only once
>> every block, or less the 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 how
>> 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 to 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=3 policy). Ideally, they should
>> constraint a pinning attacker to always attach a high feerate package
>> (commitment + CPFP) to replace the 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=3 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=3 code branch is
>> available:
>> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>>
>> ## Discovery
>>
>> In 2018, the issue of static fees for pre-signed lightning transactions
>> is made more widely known, the carve-out exemption in mempool rules to
>> mitigate in-mempool package 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 finding
>> 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 cycling
>> attack existence to 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, and 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 the
>> same" - K.
>>
>>
>>

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

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"

[Antoine Riard]

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

Hi Zeeman,

> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
HTLC-timeout transaction do not confirm.

This is not that the HTLC-timeout does not confirm. It is replaced in
cycles by C's HTLC-preimage which is still valid after `B->C` HTLC timelock
has expired. And this HTLC-preimage is subsequently replaced itself.

See the test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf

> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
`A` drops the `A====B` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
recover the HTLC funds.
> However, the feerates of the `B====C` pre-signed transactions remain at
the old, uncompetitive feerates.

This is correct that A tries to recover the HTLC funds on the `A===B`
channel.

However, there is no need to consider the fee rates nor mempool congestion
as the exploit lays on the replacement mechanism itself (in simple
scenario).

> At this point, `C` broadcasts an HTLC-success transaction with high
feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
able to use the knowledge of the preimage, as its own incoming HTLC was
already confirmed as claimed by `A`.

This is correct that `C` broadcasts an HTLC-success transaction at block
height 144.

However `C` broadcasts this high feerate transaction at _every block_
between blocks 100 and 144 to replace B's HTLC-timeout transaction.

> Let me also explain to non-Lightning experts why HTLC-timeout is
presigned in this case and why `B` cannot feebump it.

Note `B` can feebump the HTLC-timeout for anchor output channels thanks to
sighash_single | anyonecanpay on C's signature.

Le mar. 17 oct. 2023 à 11:34, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> Good morning Antoine et al.,
>
> Let me try to rephrase the core of the attack.
>
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes,
> `==` are channels):
>
>     A ===== B ===== C
>
> `A` routes `A->B->C`.
>
> The timelocks, for example, could be:
>
>    A->B timeelock = 144
>    B->C timelock = 100
>
> The above satisfies the LN BOLT requirements, as long as `B` has a
> `cltv_expiry_delta` of 44 or lower.
>
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the
> signed transactions --- commitment transaction and HTLC-timeout
> transactions --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired
> without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
> HTLC-timeout transaction do not confirm.
>
> In the mean time, `A` is still online with `B` and updates the onchain
> fees of the `A====B` channel pre-signed transactions (commitment tx and
> HTLC-timeout tx) to the latest.
>
> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
> `A` drops the `A====B` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
> recover the HTLC funds.
> However, the feerates of the `B====C` pre-signed transactions remain at
> the old, uncompetitive feerates.
>
> At this point, `C` broadcasts an HTLC-success transaction with high
> feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
> low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
> able to use the knowledge of the preimage, as its own incoming HTLC was
> already confirmed as claimed by `A`.
>
> Is the above restatement accurate?
>
> ----
>
> Let me also explain to non-Lightning experts why HTLC-timeout is presigned
> in this case and why `B` cannot feebump it.
>
> In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja
> penalty case, and are not plain HTLCs.
>
> A plain HTLC offerred by `B` to `C` would look like this:
>
>     (B && OP_CLTV) || (C && OP_HASH160)
>
> However, on the commitment transaction held by `B`, it would be infected
> by the penalty case in this way:
>
>     (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation)
>
> There are two changes:
>
> * The addition of a revocation branch `C && revocation`.
> * The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also
> includes `C`.
>
> These are necessary in case `B` tries to cheat and this HTLC is on an old,
> revoked transaction.
> If the revoked transaction is *really* old, the `OP_CLTV` would already
> impose a timelock far in the past.
> This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it
> retained this very old revoked transaction.
>
> To prevent that, `C` is added to the `B && OP_CLTV` branch.
> We also introduce an HTLC-timeout transaction, which spends the `B && C &&
> OP_CLTV` branch, and outputs to:
>
>     (B && OP_CSV) || (C && revocation)
>
> Thus, even if `B` held onto a very old revoked commitment transaction and
> attempts to spend the timelock branch (because the `OP_CLTV` is for an old
> blockheight), it still has to contend with a new output with a *relative*
> timelock.
>
> Unfortunately, this means that the HTLC-timeout transaction is pre-signed,
> and has a specific feerate.
> In order to change the feerate, both `B` and `C` have to agree to re-sign
> the HTLC-timeout transaction at the higher feerate.
>
> However, the HTLC-success transaction in this case spends the plain `(C &&
> OP_HASH160)` branch, which only involves `C`.
> This allows `C` to feebump the HTLC-success transaction arbitrarily even
> if `B` does not cooperate.
>
> While anchor outputs can be added to the HTLC-timeout transaction as well,
> `C` has a greater advantage here due to being able to RBF the HTLC-timeout
> out of the way (1 transaction), while `B` has to get both HTLC-timeout and
> a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2
> transactions).
> `C` thus requires a smaller fee to achieve a particular feerate due to
> having to push a smaller number of bytes compared to `B`.
>
> Regards,
> ZmnSCPxj
>

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

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"

[Antoine Riard]

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

Hi Ziggie,

> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
attack you observed on mainnet ? How did you monitor the chain, are the
some tools available I can run in parallel to my
> lightning software to record this kind of suspicious behaviour (which did
you use)?

Just to give a clarification no _such_ attack has been observed on mainnet,
since I and other LN maintainers have been aware of this issue. If there is
a confusion on the disclosure mail thanks to point to it, I'll correct it.

We discussed privately to experiment a demo attack in restrained dev
circles, like we have done in the past for some LN sec issues. We have
conducted one so far, multiple scenarios to look at.

I confirm the risk of exposure if an attacker targets channels with high
capacity and loose channel policies. Note there is no way to configure the
cap for the total value of outbound HTLC in-flight, which is the flow
affected.

If you would like to observe the existence of such an attack happening,
look at your mempool logs and the amount of HTLC output being
systematically conflicted out with the following sequence (HTLC-timeout -
HTLC-preimage - HTLC-timeout - ...).

As an observation note, this is not akin to a pinning attack, as there is
no "honest" or "malicious" transaction pinned in network mempools. And it
can happen without network mempools congestion.

> What's also worth mentioning here is that you do not really have to
control 2 neighbouring nodes to target your victim. If you can cycle the
attack on the tail side and delay the confirmation of the htlc- timeout
covenant the peer at the front (incoming link) of the victim will
force-close the channel and claim his timeout-path in the same way
(canceling back the initial htlc amount to the attackers initial node).

I think this is a behavior worthy of testing.

> Apart from that I think one can even introduce some kind of feebumping
race between the victim and the attacker on the tail side of the attack
making the attack even more costly. I think
> currently when lightning nodes see the preimage in the mempool (during
the time where they already can spend the same output with the
timeout-covenant) we are honest and just extract
> the preimage and don't try to race this tx output.

Local-mempool preimage monitoring has been implemented by Eclair for years
as a mitigation against old school pinning attacks on second-stage HTLC
transactions.

This mechanism has been implemented by LND in the last months, following
the report of replacement cycling attacks. As of today this is not
implemented by Core-Lightning or LDK.

> So we maybe should start feebumping this output if we end up in this
scenario? If we see the preimage and can also claim this output via the
htlc-timeout path, we should aggressively fee-bump (racing this output) our
htlc-output in addition to grabbing the preimage and claiming it on the
incoming. This is only feasible with anchor channels where we can add fees
to the htlc-covenant. This would make the attack more costly for a peer
when he knows that we use fees up to 50% of the htlc value. When you cycle
this 144 times you will be at a heavy loss trying to steal this htlc.

This is the "defensive fee mitigation" proposed in the paper. Coming with
some unknown.

> I would add another mitigation to the list for node runners to restrict
the amount and number of HTLCs  for big channels to unknown peers. It
quickly comes with a loss when the HTLCs the attacker tries to steal are
small.

See the point above on the lack of way at the spec-level to negotiate cap
on the total value of outbound HTLC in-flight.

Le mar. 17 oct. 2023 à 08:21, ziggie1984 <ziggie1984@protonmail.com> a
écrit :

> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the 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.
>
>
> Hi Antoine,
>
> thanks for this detailed explanation. This class of pinning attacks sound
> not too unlikely especially if the attacker targets channels with high
> capacity and very loose channel policies (allowing the full htlc amount to
> be the channel capacity). Could you add more details about the attack you
> observed on mainnet ? How did you monitor the chain, are the some tools
> available I can run in parallel to my lightning software to record this
> kind of suspicious behaviour (which did you use)?
> What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc-timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think currently when lightning nodes
> see the preimage in the mempool (during the time where they already can
> spend the same output with the timeout-covenant) we are honest and just
> extract the preimage and don't try to race this tx output. So we maybe
> should start feebumping this output if we end up in this scenario? If we
> see the preimage and can also claim this output via the htlc-timeout path,
> we should aggressively fee-bump (racing this output) our htlc-output in
> addition to grabbing the preimage and claiming it on the incoming. This is
> only feasible with anchor channels where we can add fees to the
> htlc-covenant. This would make the attack more costly for a peer when he
> knows that we use fees up to 50% of the htlc value. When you cycle this 144
> times you will be at a heavy loss trying to steal this htlc.
>
> I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs  for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
>
> Kind regards,
>
> ziggie
>
>
> ------- Original Message -------
> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
> antoine.riard@gmail.com> wrote:
>
> (cross-posting mempool issues identified are exposing lightning chan to
> 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-paper/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 hop 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 feerate 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 at 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 timelock 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
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the 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 how
> 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 to 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=3 policy). Ideally, they should
> constraint a pinning attacker to always attach a high feerate package
> (commitment + CPFP) to replace the 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=3 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=3 code branch is
> available:
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>
> ## Discovery
>
> In 2018, the issue of static fees for pre-signed lightning transactions is
> made more widely known, the carve-out exemption in mempool rules to
> mitigate in-mempool package 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 finding 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 cycling
> attack existence to 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, and 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 the
> same" - K.
>
>
>

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

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"

[ZmnSCPxj]

Good morning Antoine et al.,

Let me try to rephrase the core of the attack.

There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==` are channels):

    A ===== B ===== C

`A` routes `A->B->C`.

The timelocks, for example, could be:

   A->B timeelock = 144
   B->C timelock = 100

The above satisfies the LN BOLT requirements, as long as `B` has a `cltv_expiry_delta` of 44 or lower.

After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the signed transactions --- commitment transaction and HTLC-timeout transactions --- are "stuck" at the feerate at the time.

At block height 100, `B` notices the `B->C` HTLC timelock is expired without `C` having claimed it, so `B` forces the `B====C` channel onchain.
However, onchain feerates have risen and the commitment transaction and HTLC-timeout transaction do not confirm.

In the mean time, `A` is still online with `B` and updates the onchain fees of the `A====B` channel pre-signed transactions (commitment tx and HTLC-timeout tx) to the latest.

At block height 144, `B` is still not able to claim the `A->B` HTLC, so `A` drops the `A====B` channel onchain.
As the fees are up-to-date, this confirms immediately and `A` is able to recover the HTLC funds.
However, the feerates of the `B====C` pre-signed transactions remain at the old, uncompetitive feerates.

At this point, `C` broadcasts an HTLC-success transaction with high feerates that CPFPs the commitment tx.
However, it replaces the HTLC-timeout transaction, which is at the old, low feerate.
`C` is thus able to get the value of the HTLC, but `B` is now no longer able to use the knowledge of the preimage, as its own incoming HTLC was already confirmed as claimed by `A`.

Is the above restatement accurate?

----

Let me also explain to non-Lightning experts why HTLC-timeout is presigned in this case and why `B` cannot feebump it.

In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja penalty case, and are not plain HTLCs.

A plain HTLC offerred by `B` to `C` would look like this:

    (B && OP_CLTV) || (C && OP_HASH160)

However, on the commitment transaction held by `B`, it would be infected by the penalty case in this way:

    (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation)

There are two changes:

* The addition of a revocation branch `C && revocation`.
* The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also includes `C`.

These are necessary in case `B` tries to cheat and this HTLC is on an old, revoked transaction.
If the revoked transaction is *really* old, the `OP_CLTV` would already impose a timelock far in the past.
This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it retained this very old revoked transaction.

To prevent that, `C` is added to the `B && OP_CLTV` branch.
We also introduce an HTLC-timeout transaction, which spends the `B && C && OP_CLTV` branch, and outputs to:

    (B && OP_CSV) || (C && revocation)

Thus, even if `B` held onto a very old revoked commitment transaction and attempts to spend the timelock branch (because the `OP_CLTV` is for an old blockheight), it still has to contend with a new output with a *relative* timelock.

Unfortunately, this means that the HTLC-timeout transaction is pre-signed, and has a specific feerate.
In order to change the feerate, both `B` and `C` have to agree to re-sign the HTLC-timeout transaction at the higher feerate.

However, the HTLC-success transaction in this case spends the plain `(C && OP_HASH160)` branch, which only involves `C`.
This allows `C` to feebump the HTLC-success transaction arbitrarily even if `B` does not cooperate.

While anchor outputs can be added to the HTLC-timeout transaction as well, `C` has a greater advantage here due to being able to RBF the HTLC-timeout out of the way (1 transaction), while `B` has to get both HTLC-timeout and a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2 transactions).
`C` thus requires a smaller fee to achieve a particular feerate due to having to push a smaller number of bytes compared to `B`.

Regards,
ZmnSCPxj

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"

[ziggie1984]

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

> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits from the HTLC-timeout being usually broadcast by lightning nodes only once every block, or less the 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.

Hi Antoine,

thanks for this detailed explanation. This class of pinning attacks sound not too unlikely especially if the attacker targets channels with high capacity and very loose channel policies (allowing the full htlc amount to be the channel capacity). Could you add more details about the attack you observed on mainnet ? How did you monitor the chain, are the some tools available I can run in parallel to my lightning software to record this kind of suspicious behaviour (which did you use)?
What's also worth mentioning here is that you do not really have to control 2 neighbouring nodes to target your victim. If you can cycle the attack on the tail side and delay the confirmation of the htlc-timeout covenant the peer at the front (incoming link) of the victim will force-close the channel and claim his timeout-path in the same way (canceling back the initial htlc amount to the attackers initial node).

Apart from that I think one can even introduce some kind of feebumping race between the victim and the attacker on the tail side of the attack making the attack even more costly. I think currently when lightning nodes see the preimage in the mempool (during the time where they already can spend the same output with the timeout-covenant) we are honest and just extract the preimage and don't try to race this tx output. So we maybe should start feebumping this output if we end up in this scenario? If we see the preimage and can also claim this output via the htlc-timeout path, we should aggressively fee-bump (racing this output) our htlc-output in addition to grabbing the preimage and claiming it on the incoming. This is only feasible with anchor channels where we can add fees to the htlc-covenant. This would make the attack more costly for a peer when he knows that we use fees up to 50% of the htlc value. When you cycle this 144 times you will be at a heavy loss trying to steal this htlc.

I would add another mitigation to the list for node runners to restrict the amount and number of HTLCs for big channels to unknown peers. It quickly comes with a loss when the HTLCs the attacker tries to steal are small.

Kind regards,

ziggie

------- Original Message -------
On Monday, October 16th, 2023 at 18:57, Antoine Riard <antoine.riard@gmail.com> wrote:

> (cross-posting mempool issues identified are exposing lightning chan to 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-paper/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 hop 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 feerate 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 at 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 timelock 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
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits from the HTLC-timeout being usually broadcast by lightning nodes only once every block, or less the 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 how 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 to 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=3 policy). Ideally, they should constraint a pinning attacker to always attach a high feerate package (commitment + CPFP) to replace the 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=3 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=3 code branch is available:
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
>
> ## Discovery
>
> In 2018, the issue of static fees for pre-signed lightning transactions is made more widely known, the carve-out exemption in mempool rules to mitigate in-mempool package 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 finding 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 cycling attack existence to 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, and 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 the same" - K.

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