Bitcoin Optech Newsletter #121 Bitcoin Optech

This week’s newsletter describes the disclosure of two vulnerabilities
in LND and includes our regular sections with summaries of popular
questions and answers from the Bitcoin StackExchange, announcements of
releases and release candidates, and descriptions of changes to popular
Bitcoin infrastructure software.

Action items

  • Ensure LND nodes are upgraded to 0.11+: as warned in Newsletter
    #119
    , a full disclosure of two vulnerabilities in old
    versions of LND has been made public. Both vulnerabilities allow funds
    to be stolen from an affected LN node, so it is strongly recommended
    to upgrade immediately to LND 0.11.0-beta or LND 0.11.1-beta. Other LN
    implementations are not affected by the described vulnerabilities.

News

  • Full disclosures of recent LND vulnerabilities: two
    vulnerabilities affecting LND were fully disclosed this week with
    posts to the Lightning-Dev mailing list by both LND co-maintainer
    Conner Fromknecht and vulnerability discoverer Antoine Riard.

    • CVE-2020-26895 acceptance of non-standard signatures: in
      some cases, LND would accept a transaction signature that Bitcoin
      Core would not relay or mine by default. When the transaction
      containing the unrelayable signature fails to confirm, a timelock
      eventually expires and the attacker is able to steal funds they
      previously paid to the vulnerable user.

      This is a consequence of the S value in Bitcoin ECDSA signatures being equally valid on either the high side or low side of Bitcoin’s elliptical curve (which, like all such curves, is symmetric). Before segwit, inverting an S value—something anyone can do to any valid signature1—would change a transaction’s txid, a problem known as transaction malleability. After a major Bitcoin exchange lost funds by not properly handling mutated txids, Bitcoin Core 0.11.1 was released with a policy not to relay or mine transactions with S values on the high side of the curve—requiring anyone who wanted to exploit this form of malleability find someone to mine blocks with alternative software. Even though segwit eliminates this type of txid malleability for transactions that spend only segwit UTXOs, the policy is still enforced for all transactions in order to prevent wasted bandwidth and other annoyances.

      During LND’s development, two different methods of signature handling were implemented. In most cases, LND properly ensured it only sent low-S signatures that could be relayed. However, Riard discovered that LND would accept a high-S value for a successful payment, ultimately allowing an attacker to steal back a previously settled payment.

      Because anyone can invert any valid signature, LND was patched to allow it to transform any non-relayable high-S signature into a relayable low-S signature. This means any LND node that was attacked but which upgrades before the successful payment expires should be able to keep its funds. BOLTs #807 proposes to update the LN specification to automatically close channels where either party attempts to use a high-S signature (which no modern Bitcoin software should create), which Fromknecht notes LND plans to implement.

      For details, see the emails from Riard and Fromknecht.

    • CVE-2020-26896 improper preimage revelation: LND could be
      tricked into revealing an HTLC preimage before
      receiving an expected payment, allowing the payment to be stolen
      by one of the nodes that was supposed to route it.

      Imagine Alice wants to pay Bob by routing a payment through Mallory:

       Alice → Mallory → Bob (planned route)
      

      Alice starts by giving Mallory an HTLC. Mallory can’t claim this money yet because she doesn’t know the preimage for its hashlock. However, Mallory does guess that Bob is the intended receiver—so he knows the preimage. Instead of routing Alice’s payment to Bob, Mallory creates a new minimal payment secured by the same hashlock and routes it back to herself through Bob and a third-party (Carol).

       Mallory → Bob → Carol → Mallory (second payment route)
      

      Even though Mallory created this second payment, she can’t complete it because she doesn’t know the preimage for the hashlock. Instead, she closes her channel with Bob with the second payment still pending. Because of a bug in LND, Bob will use the preimage meant for the payment from Alice to settle the payment routed through his node by Mallory. This earns Bob the routing fees Mallory paid, but it also reveals the preimage to the pending HTLC Alice tried routing through Mallory. With the preimage, Mallory is able to claim the full amount of that payment without routing any part of it to Bob. Additionally, Alice receives cryptographic proof of payment even though the payment was actually stolen.

      LND’s design tried to prevent this problem by storing payment preimages separately from routing preimages, but some code was added that queried both databases, creating the bug that Riard discovered.

      Both Fromknecht and Riard note that the attack could’ve been prevented if the payment secrets feature added to all LN implementations almost a year ago had become mandatory for all invoices. This feature was designed to prevent privacy-reducing probing, particularly of multipath payments, by preventing a receiver from disclosing a payment preimage unless a payment contained a nonce included in the invoice. If it had been enforced in this case, Mallory wouldn’t know the payment secret and so couldn’t have induced Bob to disclose it even with the buggy code. Fromknecht notes that, “the upcoming v0.12.0-beta release of lnd is likely to make payment secrets required by default. We would welcome other implementations to do the same.”

      A second set of emails from Riard and Fromknecht describe this issue in detail.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.

Notable code and documentation changes

Notable changes this week in Bitcoin Core,
C-Lightning, Eclair, LND,
Rust-Lightning, libsecp256k1,
Hardware Wallet Interface (HWI), Bitcoin Improvement Proposals
(BIPs)
, and Lightning BOLTs.

  • Bitcoin Core #20198 adds three new fields to the bitcoin-wallet tool’s
    info command output. The newly added fields “Name”, “Format”, and
    “Descriptors” represent, respectively, the name of the wallet, the wallet
    database format (bdb or sqlite), and whether or not the
    wallet is a descriptor wallet.

  • C-Lightning #4046 adds the ability for commands to send notifications
    indicating command progress. It is an opt-in feature in order to be
    backwards compatible. An example use case is the original issue
    that prompted the change.

  • C-Lightning #4139 updates the multifundchannel RPC with a new
    commitment_feerate parameter that sets the initial feerate for
    commitment transactions in the channel. Previously, the same feerate
    was used for both the funding transaction and initial commitment
    transactions. This new option allows users to pay a higher feerate to
    get a channel open quickly without obliging them to pay the same
    higher feerate for commitment transactions. This is especially useful
    when using anchor outputs that allow
    commitment transactions to pay a low feerate that can be increased if
    necessary using CPFP fee bumping.

  • Eclair #1575 adds an override-feerate-tolerance setting that
    allows specifying how much your node will tolerate specific peers
    creating commitment transactions with feerates that are too low to get
    confirmed onchain quickly or too high to be reasonable. The PR
    suggests a use for this might be maintaining low-feerate channels with
    peers you trust.

  • BIPs #1003 updates the BIP322 specification of the generic
    message signing protocol
    to drop the use
    of a custom signing protocol and instead use virtual transactions that
    can be signed by many Bitcoin wallets that already accept PSBTs or raw
    Bitcoin transactions. The virtual transactions are constructed so
    that they can’t spend any bitcoins but do commit to the intended
    message. See Newsletter #118 for a summary of
    this change from when it was proposed.

Footnotes

  1. If a high S value is the coordinate (x,y), then the low S value
    is (x,-y). For Bitcoin’s secp256k1 curve over a prime field where all
    points are unsigned, you can’t simply take the negative, so you
    subtract the y coordinate in a high S value from the order of
    the curve. As BIP146 describes: “S' = 0xFFFFFFFF
    FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S
    ”.  

—Source link—

What do you think?

How to protect yourself from impermanent loss with Bancor Bankless

Harvest Finance Exploited for $25M DeFi Rate