Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D2519C0001 for ; Thu, 13 May 2021 01:06:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B9B86838C0 for ; Thu, 13 May 2021 01:06:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYFCRXbCpvWx for ; Thu, 13 May 2021 01:06:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp1.osuosl.org (Postfix) with ESMTPS id 83C0783834 for ; Thu, 13 May 2021 01:06:33 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id m9so33040311ybm.3 for ; Wed, 12 May 2021 18:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Qt1gUhl2A0GXxXYPzsaAChiZWaubxe03bpfmS9ySfWI=; b=DGIwekCXaaFUjLsfANc5BKCf5G/LqLgfyO0PcZ9Rt+Po29+AFJmsQpkun/MpM2edlB JPzG9UlI8B+Dn4AgqqGCE55ipOHi6e9kUhOYZ5pJ+tX0CDEqFsUOq4DudC952WuHUtQu /MwXZMlXBxDsdl1p6tgjG2l19NZjZFz/4e/BuztKiQFP9laP8gDpMBxnB56QcrH9P8RC gBfS+pYMzdEaviKYm1ncxT8v2RwsiLxRu5HDe5e7lhxfYIkAjf/aJwAB4gmLsviGGylt gwPmCAarpPm7c4e7zrWMADFrxM20YbryCeea3Czd4o9uBwXlTg+lnYIB0SXv77tYGudy peOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Qt1gUhl2A0GXxXYPzsaAChiZWaubxe03bpfmS9ySfWI=; b=F9Mhc4xkjVkSMJILuHBtBeGVKu8v69bt+RjdD6AmIqV2q/q7E3uqxoOKLB6GizVMEF O5eT7TV26JjW9keQRdo5uUZ9w3jEvt4/avAg+vq+Ro3LhGxOZDUuCNxFs+T/hsm24+Py KH43dSH9yhLWTNfz4/WKasJlKsbkCEJXZt/SbszPM3RUsP+sscFCBD6jmGNCnuai0Q6s xXTakbjlIMCXnBGRwSw4nzqp/M4AtOO10ePCyRNp2HWn4+WCTO6yGj0LcmuDTWbqzOpJ 2y+/Kcu64xUWeUGUu+Uw4y2ir6ufu86/G4JvdBZl8wKggkO5w5NiNts+qt6V1CNYUtTM s/+g== X-Gm-Message-State: AOAM531Esi6iQCG7Sgq1YutpmZsBtKvPgnO7q01pn9XC/rIhSjE7JV6L 7+tdc7NxRi4fZ0151WKQVepjl0JxkO57XpR9eXo= X-Google-Smtp-Source: ABdhPJysObIrWxiwbFc/mmLeobyT7AJiWxLY5jqv9YBZ5MelTjfxaXq8QI2/D5Lc9ioC8V0B/KC3VnqkpJ3k5RvIJw0= X-Received: by 2002:a25:8442:: with SMTP id r2mr8606960ybm.492.1620867992320; Wed, 12 May 2021 18:06:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olaoluwa Osuntokun Date: Wed, 12 May 2021 18:06:21 -0700 Message-ID: To: Antoine Riard , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e8fe2905c22bbc41" Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 01:06:35 -0000 --000000000000e8fe2905c22bbc41 Content-Type: text/plain; charset="UTF-8" Hi Antoine, Excellent work as usual! When this was initially reported, I suspected that btcd wasn't actually affected by this issue (proper RBF inheritance). I wrote a unit test earlier today to confirm this: https://github.com/btcsuite/btcd/pull/1719. I'm particularly fond of btcd's implementation of RBF signalling: https://github.com/btcsuite/btcd/blob/master/mempool/mempool.go#L603. The separation of concerns here makes it (IMO) much easier to follow (as well as uint test) compared to bitcoind's `MemPoolAccept::PreChecks` function. Its recursive nature makes the inherited replaceability explicit. -- Laolu On Thu, May 6, 2021 at 8:49 AM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I'm writing to report a defect in Bitcoin Core bip125 logic with minor > security and operational implications for downstream projects. Though this > defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't > impacted. > > # Problem > > Bip 125 specification describes the following signalling mechanism : > > " > This policy specifies two ways a transaction can signal that it is > replaceable. > > * Explicit signaling: A transaction is considered to have opted in to > allowing replacement of itself if any of its inputs have an nSequence > number less than (0xffffffff - 1). > > * Inherited signaling: Transactions that don't explicitly signal > replaceability are replaceable under this policy for as long as any one of > their ancestors signals replaceability and remains unconfirmed. > > One or more transactions currently in the mempool (original transactions) > will be replaced by a new transaction (replacement transaction) that spends > one or more of the same inputs if, > > # The original transactions signal replaceability explicitly or through > inheritance as described in the above Summary section. > " > > An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending > an unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable > as the child transaction signals "through inheritance". However, the > replacement code as implemented in Core's `PreChecks()` shows that this > behavior isn't enforced and Core's mempool rejects replacement attempts of > an unconfirmed child transaction. > > Branch asserting the behavior is here : > https://github.com/ariard/bitcoin/commits/2021-03-test-rbf > > # Solution > > The defect has not been patched. > > # Downstream Projects Affected > > * LN : State-of-the-art pinning attacks against second-stage HTLCs > transactions were thought to be only possible by exploiting RBF rule 3 on > the necessity of a higher absolute fee [0]. However, this replacement > defect opens the way for an attacker to only pin with an opt-out child > without a higher fee than the honest competing transaction. This lowers the > cost of attack as the malicious pinning transaction only has to be above > mempools'min feerate. This also increases odds of attack success for a > reduced feerate diminishes odds of confirmation ending the pinning. > > A functional test demo illustrating cases is available on this branch: > https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings > > LN nodes operators concerned by this defect might favor anchor outputs > channels, fully mitigating this specific pinning vector. > > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly > signal RBF. > > * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if > the coinjoin transaction is still laying in network mempools, if a > fee-bumping output is spendable by any protocol participant, this > fee-bumping mechanism might be halted by a malicious protocol participant > broadcasting an low-feerate opt-out child. According to bip125, if the > coinjoin parent tx signals replaceability, the child transaction should be > replaceable, whatever its signaling. However Core doesn't apply this > policy. RBF of the coinjoin transaction itself should be used as a > fallback. I'm not aware of any deployed coinjoin using such > "anyone-can-bump" fee-bumping strategy. > > * Simple wallets : RBF engines' behaviors might be altered in ways not > matching the intent of their developers. I invite RBF engines dev to verify > what those components are doing in the light of disclosed information. > > # Discovery > > While reviewing the LN dual-funding flow, I inquired on potential new DoS > vectors introduced by relying on counterparty utxos in this following > analysis [1]. The second DoS issue "RBF opt-out by a Counterparty > Double-Spend" is relying on a malicious chain of transactions where the > parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the > child, servicing as a pinning transaction, opt-out from the RBF policy. > This pinning trick conception was matching my understanding of Core code > but while reading again the specification, I observed that it was > inconsistent from the inherited signaling mechanism as described in the > bip's "Summary" section. > > After exercising the logic, I did submit the defect to Dave Harding, > asking confirmation of divergence between Bitcoin Core and BIP 125. Soon > after, he did confirm it and pointed that the defect has been there since > the 2015's PR introducing the opt-in RBF, advicing to to consider security > implications for deployed second-layer protocols. After noticing the minor > implications for pinning attacks on second-stage LN transactions while > talking with Matt Corallo, I did disclose to the Bitcoin Core security list. > > My initial report was recommending avoiding a covert patch in the mempool > as risks of introducing DoS in this part of the codebase seemed to outweigh > security of deployed LN channels. This direction was agreed by the opinions > expressed on the security list. Beyond, there was a lack of agreement on > how to proceed with the disclosure as so far in the history project, > transaction relay policy have not been considered as strongly reliable. > Though from now on, L2 protocols like Lightning are making assumptions on > subset of this policy for their safety, such as the highlighted RBF one. > > Defect was disclosed to the LN projects maintainers, informing them that > currently in deployment anchor outputs protocol upgrade was mitigating > against this defect though old channels will stay vulnerable. To the best > of my knowledge, I didn't identify other deployed protocols of which coins > safety are impacted by this defect. > > # Ecosystem Observations > > This long-standing defect with benign security implications provided an > opportunity to exercise coordinated security disclosure across layers and > development teams. > > IMO, it underlies few interesting points: > * the lack of an established policy for coordinated security disclosures > between a base layer implementation and its downstream projects > * the lack of a clear methodology to identify downstream projects affected > by a transaction relay policy wreckage > * the lack of minimally-disruptive, emergency upgrade mechanisms > implemented by downstream projects [2] > > Finally, security implications for downstream projects provoked by base > layer issues shouldn't be minimized as they do have a risk of windblow on > base layer operations. I believe we should minimize risks of disaster > scenarios such as thousands of LN channels manually closed by worried > operators due to a non-concerted security disclosure, provoking mempool > cloaks and disrupting regular transactions for a while. > > # Timeline > > 2021-03-18 : Defect discovered, report to Dave Harding original author of > bip125, confirmation of the defect > 2021-03-19 : Disclosure to the Bitcoin Core security list, Dave Harding, > Matt Corallo, acknowledgment of the issue > 2021-04-05 : Disclosure to the LN projects maintainers (c-lightning, lnd, > eclair, electrum, rust-lightning) > 2021-04-28 : CVE-2021-31876 assigned > 2021-05-06 : Full disclosure to the bitcoin-dev mailing list > > I believe the information reported is correct and reflects the best of my > knowledge, please point any shortcoming. > > Cheers, > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html > [1] See "On Mempool Funny Games against Multi-Party Funded Transactions", > published 2021-05-06 > [2] Such as > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000e8fe2905c22bbc41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

Excellent work as usual!

When t= his was initially reported, I suspected that btcd wasn't actually
af= fected by this issue (proper RBF inheritance). I wrote a unit test earlier<= br>today to confirm this: https://github.com/btcsuite/btcd/pull/1719.

I'm parti= cularly fond of btcd's implementation of RBF signalling:
https= ://github.com/btcsuite/btcd/blob/master/mempool/mempool.go#L603.
The separation of concerns here makes it (IMO) much easier to follow (as<= br>well as uint test) compared to bitcoind's `MemPoolAccept::PreChecks`=
function. Its recursive nature makes the inherited replaceability expli= cit.

-- Laolu


On Thu, May 6, 2021 at 8:49 AM Antoine Riard = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi,

I&#= 39;m writing to report a defect in Bitcoin Core bip125 logic with minor sec= urity and operational implications for downstream projects. Though this def= ect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn'= t impacted.

# Problem

Bip 125 specification describes the fol= lowing signalling mechanism :

"
This policy specifies two wa= ys a transaction can signal that it is replaceable.

* Explicit signa= ling: A transaction is considered to have opted in to allowing replacement = of itself if any of its inputs have an nSequence number less than (0xffffff= ff - 1).

* Inherited signaling: Transactions that don't explicit= ly signal replaceability are replaceable under this policy for as long as a= ny one of their ancestors signals replaceability and remains unconfirmed.
One or more transactions currently in the mempool (original transacti= ons) will be replaced by a new transaction (replacement transaction) that s= pends one or more of the same inputs if,

# The original transactions= signal replaceability explicitly or through inheritance as described in th= e above Summary section.
"

An unconfirmed child transaction = with nSequence =3D 0xff_ff_ff_ff spending an unconfirmed parent with nSeque= nce <=3D 0xff_ff_ff_fd should be replaceable as the child transaction si= gnals "through inheritance". However, the replacement code as imp= lemented in Core's `PreChecks()` shows that this behavior isn't=C2= =A0 enforced and Core's mempool rejects replacement attempts of an unco= nfirmed child transaction.

Branch asserting the behavior is here : <= a href=3D"https://github.com/ariard/bitcoin/commits/2021-03-test-rbf" targe= t=3D"_blank">https://github.com/ariard/bitcoin/commits/2021-03-test-rbf=

# Solution

The defect has not been patched.

# Downstr= eam Projects Affected

* LN : State-of-the-art pinning attacks agains= t second-stage HTLCs transactions were thought to be only possible by explo= iting RBF rule 3 on the necessity of a higher absolute fee [0]. However, th= is replacement defect opens the way for an attacker to only pin with an opt= -out child without a higher fee than the honest competing transaction. This= lowers the cost of attack as the malicious pinning transaction only has to= be above mempools'min feerate. This also increases odds of attack succ= ess for a reduced feerate diminishes odds of confirmation ending the pinnin= g.

A functional test demo illustrating cases is available on this b= ranch: https://github.com/ariard/bitcoin/commit= s/2021-05-htlc-preimage-pinnings

LN nodes operators concerned by= this defect might favor anchor outputs channels, fully mitigating this spe= cific pinning vector.

* Onchain DLC/Coinswap/Vault : Those contract = protocols have also multiple stages of execution with time-sensitive transa= ctions opening the way to pinning attacks. Those protocols being non-deploy= ed or in early phase, I would recommend that any in-protocol competing tran= sactions explicitly signal RBF.

* Coinjoin/Cut-Through : if CPFP is = employed as a fee-bumping strategy, if the coinjoin transaction is still la= ying in network mempools, if a fee-bumping output is spendable by any proto= col participant, this fee-bumping mechanism might be halted by a malicious = protocol participant broadcasting an low-feerate opt-out child. According t= o bip125, if the coinjoin parent tx signals replaceability, the child trans= action should be replaceable, whatever its signaling. However Core doesn= 9;t apply this policy. RBF of the coinjoin transaction itself should be use= d as a fallback. I'm not aware of any deployed coinjoin using such &quo= t;anyone-can-bump" fee-bumping strategy.

* Simple wallets : RBF= engines' behaviors might be altered in ways not matching the intent of= their developers. I invite RBF engines dev to verify what those components= are doing in the light of disclosed information.

# Discovery
While reviewing the LN dual-funding flow, I inquired on potential new DoS = vectors introduced by relying on counterparty utxos in this following analy= sis [1]. The second DoS issue "RBF opt-out by a Counterparty Double-Sp= end" is relying on a malicious chain of transactions where the parent = is signaling RBF opt-in through nSequence<=3D0xff_ff_ff_ff-1 but the chi= ld, servicing as a pinning transaction, opt-out from the RBF policy. This p= inning trick conception was matching my understanding of Core code but whil= e reading again the specification, I observed that it was inconsistent from= the inherited signaling mechanism as described in the bip's "Summ= ary" section.

After exercising the logic, I did submit the defe= ct to Dave Harding, asking confirmation of divergence between Bitcoin Core = and BIP 125. Soon after, he did confirm it and pointed that the defect has = been there since the 2015's PR introducing the opt-in RBF, advicing to = to consider security implications for deployed second-layer protocols. Afte= r noticing the minor implications for pinning attacks on second-stage LN tr= ansactions while talking with Matt Corallo, I did disclose to the Bitcoin C= ore security list.

My initial report was recommending avoiding a cov= ert patch in the mempool as risks of introducing DoS in this part of the co= debase seemed to outweigh security of deployed LN channels. This direction = was agreed by the opinions expressed on the security list. Beyond, there wa= s a lack of agreement on how to proceed with the disclosure as so far in th= e history project, transaction relay policy have not been considered as str= ongly reliable. Though from now on, L2 protocols like Lightning are making = assumptions on subset of this policy for their safety, such as the highligh= ted RBF one.

Defect was disclosed to the LN projects maintainers, in= forming them that currently in deployment anchor outputs protocol upgrade w= as mitigating against this defect though old channels will stay vulnerable.= To the best of my knowledge, I didn't identify other deployed protocol= s of which coins safety are impacted by this defect.

# Ecosyst= em Observations

This long-standing defect with benign secu= rity implications provided an opportunity to exercise coordinated security = disclosure across layers and development teams.

IMO, it underlies f= ew interesting points:
* the lack of an established policy for coordinat= ed security disclosures between a base layer implementation and its downstr= eam projects
* the lack of a clear methodology to identify downstream pr= ojects affected by a transaction relay policy wreckage
* the lack of min= imally-disruptive, emergency upgrade mechanisms implemented by downstream p= rojects [2]

Finally, security implications for downstream projects p= rovoked by base layer issues shouldn't be minimized as they do have a r= isk of windblow on base layer operations. I believe we should minimize risk= s of disaster scenarios such as thousands of LN channels manually closed by= worried operators due to a non-concerted security disclosure, provoking me= mpool cloaks and disrupting regular transactions for a while.

# Time= line

2021-03-18 : Defect discovered, report to Dave Harding original= author of bip125, confirmation of the defect
2021-03-19 : Disclosure to= the Bitcoin Core security list, Dave Harding, Matt Corallo, acknowledgment= of the issue
2021-04-05 : Disclosure to the LN projects maintainers (c-= lightning, lnd, eclair, electrum, rust-lightning)
2021-04-28 : CVE-2021-= 31876 assigned
2021-05-06 : Full disclosure to the bitcoin-dev mailing l= ist

I believe the information reported is correct and reflects the b= est of my knowledge, please point any shortcoming.

Cheers,
Antoin= e

[0] https://lists.linuxfoundat= ion.org/pipermail/lightning-dev/2020-April/002639.html
[1] See "= ;On Mempool Funny Games against Multi-Party Funded Transactions", publ= ished 2021-05-06
[2] Such as https://= lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e8fe2905c22bbc41--