{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-05-06\n📝 Original message:Hi,\n\nI'm writing to report a defect in Bitcoin Core bip125 logic with minor\nsecurity and operational implications for downstream projects. Though this\ndefect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't\nimpacted.\n\n# Problem\n\nBip 125 specification describes the following signalling mechanism :\n\n\"\nThis policy specifies two ways a transaction can signal that it is\nreplaceable.\n\n* Explicit signaling: A transaction is considered to have opted in to\nallowing replacement of itself if any of its inputs have an nSequence\nnumber less than (0xffffffff - 1).\n\n* Inherited signaling: Transactions that don't explicitly signal\nreplaceability are replaceable under this policy for as long as any one of\ntheir ancestors signals replaceability and remains unconfirmed.\n\nOne or more transactions currently in the mempool (original transactions)\nwill be replaced by a new transaction (replacement transaction) that spends\none or more of the same inputs if,\n\n# The original transactions signal replaceability explicitly or through\ninheritance as described in the above Summary section.\n\"\n\nAn unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an\nunconfirmed parent with nSequence \u003c= 0xff_ff_ff_fd should be replaceable as\nthe child transaction signals \"through inheritance\". However, the\nreplacement code as implemented in Core's `PreChecks()` shows that this\nbehavior isn't  enforced and Core's mempool rejects replacement attempts of\nan unconfirmed child transaction.\n\nBranch asserting the behavior is here :\nhttps://github.com/ariard/bitcoin/commits/2021-03-test-rbf\n\n# Solution\n\nThe defect has not been patched.\n\n# Downstream Projects Affected\n\n* LN : State-of-the-art pinning attacks against second-stage HTLCs\ntransactions were thought to be only possible by exploiting RBF rule 3 on\nthe necessity of a higher absolute fee [0]. However, this replacement\ndefect opens the way for an attacker to only pin with an opt-out child\nwithout a higher fee than the honest competing transaction. This lowers the\ncost of attack as the malicious pinning transaction only has to be above\nmempools'min feerate. This also increases odds of attack success for a\nreduced feerate diminishes odds of confirmation ending the pinning.\n\nA functional test demo illustrating cases is available on this branch:\nhttps://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings\n\nLN nodes operators concerned by this defect might favor anchor outputs\nchannels, fully mitigating this specific pinning vector.\n\n* Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple\nstages of execution with time-sensitive transactions opening the way to\npinning attacks. Those protocols being non-deployed or in early phase, I\nwould recommend that any in-protocol competing transactions explicitly\nsignal RBF.\n\n* Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if\nthe coinjoin transaction is still laying in network mempools, if a\nfee-bumping output is spendable by any protocol participant, this\nfee-bumping mechanism might be halted by a malicious protocol participant\nbroadcasting an low-feerate opt-out child. According to bip125, if the\ncoinjoin parent tx signals replaceability, the child transaction should be\nreplaceable, whatever its signaling. However Core doesn't apply this\npolicy. RBF of the coinjoin transaction itself should be used as a\nfallback. I'm not aware of any deployed coinjoin using such\n\"anyone-can-bump\" fee-bumping strategy.\n\n* Simple wallets : RBF engines' behaviors might be altered in ways not\nmatching the intent of their developers. I invite RBF engines dev to verify\nwhat those components are doing in the light of disclosed information.\n\n# Discovery\n\nWhile reviewing the LN dual-funding flow, I inquired on potential new DoS\nvectors introduced by relying on counterparty utxos in this following\nanalysis [1]. The second DoS issue \"RBF opt-out by a Counterparty\nDouble-Spend\" is relying on a malicious chain of transactions where the\nparent is signaling RBF opt-in through nSequence\u003c=0xff_ff_ff_ff-1 but the\nchild, servicing as a pinning transaction, opt-out from the RBF policy.\nThis pinning trick conception was matching my understanding of Core code\nbut while reading again the specification, I observed that it was\ninconsistent from the inherited signaling mechanism as described in the\nbip's \"Summary\" section.\n\nAfter exercising the logic, I did submit the defect to Dave Harding, asking\nconfirmation of divergence between Bitcoin Core and BIP 125. Soon after, he\ndid confirm it and pointed that the defect has been there since the 2015's\nPR introducing the opt-in RBF, advicing to to consider security\nimplications for deployed second-layer protocols. After noticing the minor\nimplications for pinning attacks on second-stage LN transactions while\ntalking with Matt Corallo, I did disclose to the Bitcoin Core security list.\n\nMy initial report was recommending avoiding a covert patch in the mempool\nas risks of introducing DoS in this part of the codebase seemed to outweigh\nsecurity of deployed LN channels. This direction was agreed by the opinions\nexpressed on the security list. Beyond, there was a lack of agreement on\nhow to proceed with the disclosure as so far in the history project,\ntransaction relay policy have not been considered as strongly reliable.\nThough from now on, L2 protocols like Lightning are making assumptions on\nsubset of this policy for their safety, such as the highlighted RBF one.\n\nDefect was disclosed to the LN projects maintainers, informing them that\ncurrently in deployment anchor outputs protocol upgrade was mitigating\nagainst this defect though old channels will stay vulnerable. To the best\nof my knowledge, I didn't identify other deployed protocols of which coins\nsafety are impacted by this defect.\n\n# Ecosystem Observations\n\nThis long-standing defect with benign security implications provided an\nopportunity to exercise coordinated security disclosure across layers and\ndevelopment teams.\n\nIMO, it underlies few interesting points:\n* the lack of an established policy for coordinated security disclosures\nbetween a base layer implementation and its downstream projects\n* the lack of a clear methodology to identify downstream projects affected\nby a transaction relay policy wreckage\n* the lack of minimally-disruptive, emergency upgrade mechanisms\nimplemented by downstream projects [2]\n\nFinally, security implications for downstream projects provoked by base\nlayer issues shouldn't be minimized as they do have a risk of windblow on\nbase layer operations. I believe we should minimize risks of disaster\nscenarios such as thousands of LN channels manually closed by worried\noperators due to a non-concerted security disclosure, provoking mempool\ncloaks and disrupting regular transactions for a while.\n\n# Timeline\n\n2021-03-18 : Defect discovered, report to Dave Harding original author of\nbip125, confirmation of the defect\n2021-03-19 : Disclosure to the Bitcoin Core security list, Dave Harding,\nMatt Corallo, acknowledgment of the issue\n2021-04-05 : Disclosure to the LN projects maintainers (c-lightning, lnd,\neclair, electrum, rust-lightning)\n2021-04-28 : CVE-2021-31876 assigned\n2021-05-06 : Full disclosure to the bitcoin-dev mailing list\n\nI believe the information reported is correct and reflects the best of my\nknowledge, please point any shortcoming.\n\nCheers,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html\n[1] See \"On Mempool Funny Games against Multi-Party Funded Transactions\",\npublished 2021-05-06\n[2] Such as\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210506/80fed090/attachment-0001.html\u003e"}