From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2D1EDC0001 for ; Thu, 6 May 2021 13:56:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1B91E607C8 for ; Thu, 6 May 2021 13:56:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg5SNyNEjawk for ; Thu, 6 May 2021 13:56:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by smtp3.osuosl.org (Postfix) with ESMTPS id 49573606E2 for ; Thu, 6 May 2021 13:56:07 +0000 (UTC) Received: by mail-wm1-x32b.google.com with SMTP id t11-20020a05600c198bb02901476e13296aso3113629wmq.0 for ; Thu, 06 May 2021 06:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Pji776QKCMkPnWVdYH85rvDPsm/oDD9X3TQzTIEOG40=; b=gqKAq2dxbzwjGSCFAq2Lx80ylsUvdGnb7ZVprDFmpm39bK1RzcgYRnR3nQEA63fMU+ 56NN4M8mLQZYXR6FCsTTdEmFTpPj3KYoxQYADZCZobE0/F9KhUkp4dbQFrNyc++Upk0R RyCZZYRXsdKy8WPL9cibWJButdN3y/ZUeapmVFAzQeGyt0xwkPHVkpnkZU5RFpKyraIz qwxtZrsz/7cjkO2hhRdY8qNbvqzwiTOZ90Kb0D8u/k9edGPherH+7D/LyhEZwdwjUvmT sbjLJzzU8HX10vcQhDs0Sgi3ksI7t5ShMBecftq9qWJvlou1ODLXIXKSzdF7qOzmsHe9 4xvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pji776QKCMkPnWVdYH85rvDPsm/oDD9X3TQzTIEOG40=; b=WKFl7bnhNctmnRCHJNCHdfh3ZislSM8adiSAzXcCQRt6A2XOXPbdvyl+wC+1VbX6Jv MludDAzdVuEd+8u6nZLBhYFmktz2dkF18yFBZ64Mz83ExI+/X4f9FkfVklWRJ8c9LWCz tXFi5HkIOt7yXZtQR6J9i3yTDXAVsr8TdO+EjkR0F/Cg5LxSxNhSsvqktNMQiCyGY6W3 6aiCQXv4fCOa7ZVr8NoBYIWZRThVbqfD1urGZ4VaUpAYHYx+PmZ4K5YzvTxfHyHN7un5 56ZHnJoYRBsv/A8bnaDYP1++uEwsyVXMOSdMhIkYSBy2k5vOMDqRtaMzRPeg+LdzKTIp VGtQ== X-Gm-Message-State: AOAM5328M9rYBCpcJ2IHV+70t6UvNlh/d6IUv5LXoogwO/xPaUpXroYF kO10ZqM1fIm5Qvz6fTOwNJ5zfAvwMNWYxzvps1fLM5ZKN3h5KQ== X-Google-Smtp-Source: ABdhPJyKXGOBp/03Iuxh+FIpFmSdi0FGdFby2WBeaWhHSGKIG9SW5ZKbBZKIisF8w7IfrMhRKXArvpQcQWqPDf/6KGE= X-Received: by 2002:a1c:4102:: with SMTP id o2mr15189415wma.177.1620309364997; Thu, 06 May 2021 06:56:04 -0700 (PDT) MIME-Version: 1.0 From: Antoine Riard Date: Thu, 6 May 2021 09:55:53 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000020807005c1a9ac3b" X-Mailman-Approved-At: Thu, 06 May 2021 15:48:29 +0000 Subject: [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, 06 May 2021 13:56:09 -0000 --00000000000020807005c1a9ac3b Content-Type: text/plain; charset="UTF-8" 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 --00000000000020807005c1a9ac3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm writing to report a defect in Bitc= oin Core bip125 logic with minor security and operational implications for = downstream projects. Though this defect grieves Bitcoin Core nodes 0.12.0 a= nd above, base layer safety isn't impacted.

# Problem

Bip= 125 specification describes the following signalling mechanism :

&q= uot;
This policy specifies two ways a transaction can signal that it is = replaceable.

* Explicit signaling: A transaction is considered to ha= ve 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 replaceabl= e under this policy for as long as any one of their ancestors signals repla= ceability and remains unconfirmed.

One or more transactions currentl= y in the mempool (original transactions) will be replaced by a new transact= ion (replacement transaction) that spends one or more of the same inputs if= ,

# The original transactions signal replaceability explicitly or th= rough inheritance as described in the above Summary section.
"
<= br>An unconfirmed child transaction with nSequence =3D 0xff_ff_ff_ff spendi= ng an unconfirmed parent with nSequence <=3D 0xff_ff_ff_fd should be rep= laceable as the child transaction signals "through inheritance". = However, the replacement code as implemented in Core's `PreChecks()` sh= ows that this behavior isn't=C2=A0 enforced and Core's mempool reje= cts replacement attempts of an unconfirmed child transaction.

Branch= asserting the behavior is here : https://github.com/ariard/bitcoin/commits/202= 1-03-test-rbf

# Solution

The defect has not been patched.=

# Downstream Projects Affected

* LN : State-of-the-art pinni= ng 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 onl= y 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 transa= ction only has to be above mempools'min feerate. This also increases od= ds of attack success for a reduced feerate diminishes odds of confirmation = ending the pinning.

A functional test demo illustrating cases is av= ailable 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 spec= ific pinning vector.

* Onchain DLC/Coinswap/Vault : Those contract p= rotocols have also multiple stages of execution with time-sensitive transac= tions opening the way to pinning attacks. Those protocols being non-deploye= d or in early phase, I would recommend that any in-protocol competing trans= actions explicitly signal RBF.

* Coinjoin/Cut-Through : if CPFP is e= mployed as a fee-bumping strategy, if the coinjoin transaction is still lay= ing in network mempools, if a fee-bumping output is spendable by any protoc= ol participant, this fee-bumping mechanism might be halted by a malicious p= rotocol participant broadcasting an low-feerate opt-out child. According to= bip125, if the coinjoin parent tx signals replaceability, the child transa= ction 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 v= ectors introduced by relying on counterparty utxos in this following analys= is [1]. The second DoS issue "RBF opt-out by a Counterparty Double-Spe= nd" is relying on a malicious chain of transactions where the parent i= s signaling RBF opt-in through nSequence<=3D0xff_ff_ff_ff-1 but the chil= d, servicing as a pinning transaction, opt-out from the RBF policy. This pi= nning 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 "Summa= ry" section.

After exercising the logic, I did submit the defec= t to Dave Harding, asking confirmation of divergence between Bitcoin Core a= nd BIP 125. Soon after, he did confirm it and pointed that the defect has b= een there since the 2015's PR introducing the opt-in RBF, advicing to t= o consider security implications for deployed second-layer protocols. After= noticing the minor implications for pinning attacks on second-stage LN tra= nsactions while talking with Matt Corallo, I did disclose to the Bitcoin Co= re security list.

My initial report was recommending avoiding a cove= rt patch in the mempool as risks of introducing DoS in this part of the cod= ebase seemed to outweigh security of deployed LN channels. This direction w= as 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 stro= ngly reliable. Though from now on, L2 protocols like Lightning are making a= ssumptions on subset of this policy for their safety, such as the highlight= ed RBF one.

Defect was disclosed to the LN projects maintainers, inf= orming them that currently in deployment anchor outputs protocol upgrade wa= s 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.

# Ecosyste= m Observations

This long-standing defect with benign secur= ity implications provided an opportunity to exercise coordinated security d= isclosure across layers and development teams.

IMO, it underlies fe= w interesting points:
* the lack of an established policy for coordinate= d security disclosures between a base layer implementation and its downstre= am projects
* the lack of a clear methodology to identify downstream pro= jects affected by a transaction relay policy wreckage
* the lack of mini= mally-disruptive, emergency upgrade mechanisms implemented by downstream pr= ojects [2]

Finally, security implications for downstream projects pr= ovoked by base layer issues shouldn't be minimized as they do have a ri= sk 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 mem= pool cloaks and disrupting regular transactions for a while.

# Timel= ine

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-l= ightning, lnd, eclair, electrum, rust-lightning)
2021-04-28 : CVE-2021-3= 1876 assigned
2021-05-06 : Full disclosure to the bitcoin-dev mailing li= st

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

Cheers,
Antoine=

[0] https://lists.linuxfoundation.org/pipermail/l= ightning-dev/2020-April/002639.html
[1] See "On Mempool Funny G= ames against Multi-Party Funded Transactions", published 2021-05-06[2] Such as https://lists.linuxfoundation.org/pipermail/l= ightning-dev/2020-July/002763.html
--00000000000020807005c1a9ac3b--