path: root/00/030edc34587352dfde2953a8eef39c3d09f010

Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D54A5C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:51:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id AF909405BC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:51:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id yMLtH3WUkcOS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:51:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
 by smtp2.osuosl.org (Postfix) with ESMTP id 56357400C7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:51:42 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.215])
 (Authenticated sender: luke-jr)
 by zinan.dashjr.org (Postfix) with ESMTPSA id 4695F38A001D;
 Tue, 11 May 2021 21:50:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
 t=1620769900; bh=dBhlRN4+oyRKna1JTASMvzTm8uNFW1ls5BZBayMcJKY=;
 h=From:To:Subject:Date:References:In-Reply-To;
 b=mZMZC/Y6iJ7W79xH9jcJLxM56dxUFVJG9sVCxezlT2Lh2LLX8MmF36lDg9qZ89nkP
 cijPImwco5aCstYgzUEClt5jZHtrNazA8ai+mWjcRrrQmHJ99/A0yKodHQtfGbl/Rm
 vE7NL9cMp5JOumUzpxPO6A4V6yvUWFB+diK3v+3M=
X-Hashcash: 1:25:210511:bitcoin-dev@lists.linuxfoundation.org::fmTbHCSD6HMRp4p0:bVl2A
X-Hashcash: 1:25:210511:antoine.riard@gmail.com::oGpV6WoDczzu1Hfv:bAyEW
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 11 May 2021 21:50:50 +0000
User-Agent: KMail/1.9.10
References: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
In-Reply-To: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202105112150.51410.luke@dashjr.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2021 21:51:43 -0000

Is there a list of software impacted by this CVE, and the versions it is fixed 
in?

(Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy 
matter, not part of the consensus rules and never safe to rely on in any 
case...)


On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev 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