{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-10-04\n📝 Original message:\nHi,\n\nI'm writing a report to disclose specification-level vulnerabilities\naffecting the Lightning implementations.\n\nThe vulnerabilities are expected to be patched in:\n* Eclair: v0.6.2+ (CVE-2021-41591)\n* LND: v0.13.3+ (CVE-2021-41592)\n* LDK: v0.0.102 (not released as production software yet)\n\nThe vulnerabilities are also affecting c-lightning (CVE-2021-41593).\n\nThose vulnerabilities can be exploited in a wide range of attacks, going\nfrom fee blackmailing of node operators, burning liquidity of your\ncompeting LSPs or even stealing your counterparty channel balance if you\navail mining capabilities. Exercise of the vulnerability revealed that a\nmajority of the balance funds can be at loss.\n\nCredit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust\nexploitation and multiple insights about attacks.\n\nThanks to Bastien Teinturier and Matt Corallo for numerous contributions\nabout mitigations development.\n\n# Problem\n\nThe current BOLT specification only requires Alice's `dust_limit_satoshis`\n(applied on Alice's commitment) to be under Alice's\n`channel_reserve_satoshis` (applied on Bob). As those 2 parameters are\nselectable by Alice, she can inflate the dust limit until reaching the\nimplementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%\nof chan capacity).\n\nAny in-flight incoming HTLC under Alice's dust limit will be converted as\nminer fees on Alice's commitment. This HTLC is deducted from Bob's balance\nand as such they're still owned by Bob, until resolution (i.e a RAA\nremoving the HTLC from Alice's commitment). This limitation only applies\nper-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs\nburned as fees. Therefore, Alice is free to inflict a substantial loss to\nBob funds by publishing her commitment on-chain.\n\nIn-flight outgoing HTLC are also committed as fees on Bob's commitment if\nthey're under Bob's threshold. Alice can also exploit from this angle by\ncircular routing HTLCs until reaching Bob's\n`max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob\ngoes on-chain to timeout an offered HTLC or claim an accepted HTLC.\n\nDust HTLC processing can be also exploited at `update_fee` reception.\n\nAs the BOLT3's fees computation encompasses the negotiated feerate from\n`update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be\ntrimmed, the amount of balance at risk is a function of current mempool\nfeerates.\n\nThe maximum of funds at risk on a counterparty commitment is:\n\ncounterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's\n`feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's\n`max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +\ncounterparty's `dust_limit_satoshis`)\n\nIf the opener is also the attacker, the negotiated feerate can be\nmanipulated beyond the \"honest\" mempool feerates only upper bounded\nimplementation-defined value (before fixes, LDK: 2 * high-feerate of our\nfee-estimator). If the opener is the victim, the negotiated feerate is\nstill a safety concern in case of spontaneous mempool spikes.\n\nNote, `anchors_zero_htlc_fee` channels are not affected by the feerate\ninflation as the trimmed-to-dust fee computation mechanism for 2nd-stage\nHTLC is removed. They're still at risk of the sum of the HTLCs under the\ndust limit being maliciously burned.\n\n# Solution\n\nA first mitigation is to verify the counterparty's announced\n`dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)\nreception and reject if it's estimated too large (see #894)\n\nFor LDK, we choose the value of 660 satoshis as it's beyond the highest\ndust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of\nsafety. Propagation of Lightning time-sensitive transactions shouldn't be\naffected.\n\nA second mitigation is to define a new configurable limit\n`max_dust_htlc_exposure` and apply this one at incoming and outgoing of\nHTLC.\n\nFor LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this\nvalue as a substantial loss for our class of users. Setting this too low\nmay prevent the sending or receipt of low-value HTLCs on high-traffic\nnodes. A node operator should fine-tune this value in function of what\nqualifies as an acceptable loss.\n\nWe would like to ensure that the node isn't suddenly exposed to\nsignificantly more trimmed balance if the feerate increases when we have\nseveral HTLCs pending which are near the dust limit.\n\nTo achieve this goal, we introduce a new `dust_buffer_feerate` defined as\nthe maximum of either 2530 sats per kWU or 125% of the current\n`feerate_per_kw` (implementation-defined values).\n\nThen, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to the\ncounterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the\n`dust_buffer_feerate`. If the `amount_msat` plus the\n`dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,\nthe HTLC should be failed once it's committed.\n\nUpon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the\ncounterparty's `dust_limit_satoshis`  plus the HTLC-success fee at the\n`dust_buffer_feerate`. If the `amount_msat` plus the\n`dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,\nthe HTLC should not be sent and fail without forwarding.\n\nThe check symmetry must also be applied on holder commitment transactions.\nSee PR #919 for more details.\n\nA last mitigation is ensuring that at `update_fee` reception, the pending\n`dust_balance` at the new proposed feerate isn't superior to\n`max_dust_htlc_exposure_msat`.\n\n# Background\n\nThe dust limit is a base layer policy stopping the relay of a transaction\nif one of its outputs is under a given threshold. The goal of this policy\nis to prevent the pollution of the UTXO set with low-value outputs and as\nsuch increase the amount of work done by full-nodes.\n\nLightning commitment transactions should be able to propagate at any point\nduring the channel lifetime to unilaterally enforce on-chain a balance. A\nLightning commitment transaction with one of its outputs below the dust\nlimit would fail to relay and thus jeopardizes funds safety.\n\nTo prevent this, BOLT2 requires counterparties to announce a\n`dust_limit_satoshis` during channel opening (at\n`open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must\nbe under the same party's `channel_reserve_satoshis`. This value is static\nfor the channel lifetime.\n\nDuring commitment signatures exchange, each counterparty's limit is applied\non each counterparty's commitment (e.g A's `dust_limit_satoshis` is applied\non A's commitment, though both A and B have to generate and sign the\ntransaction). An output below this limit is trimmed to fees and won't\nmaterialize on the commitment.\n\nThe specification didn't require that the `open_channel`/`accept_channel`\nreceiver verify that the announced `dust_limit_satoshis` isn't too large.\n\nThe specification didn't require that the sum of the dust HTLC committed as\nfees was verified against an upper bound.\n\n# Discovery\n\nVulnerabilities around our dust HTLC processing have been known for years\nby some LN developers/researchers.\n\nDuring Q1 2019, private discussions on the Rust-Lightning-side (LDK before\nmarketing rebranding) about potential safety risks around dust HTLC\nprocessing.\n\nIn November 2019, Rusty Russell (c-lightning) opened an issue against the\nspecification mentioning the lack of check of counterparty's dust limit\n(#696).\n\nIn May 2020, I published a high-level attack scenario \"Miners Dust\nInflation attacks on Lightning Network\", leveraging this lack.\n\nIn February 2021, I did a test of the first vulnerability against LND\nsoftware and successfully burnt the majority of the targeted node balance\nin fees. As it sounds to me like a check missing in the specification, I\nnotified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed\non the LDK-side.\n\nIn July 2021, in the context of `option_dusty_htlcs_uncounted` discussions,\nEugene Spiegel (LND) reported on how to exploit the trimmed-to-dust\nmechanism at `update_fee` reception. Discussions followed on the best way\nto mitigate this new vector.\n\nDuring August 2021, mitigations were developed and released on the\nLDK-side. vulnerabilities were disclosed to other Lightning projects (Muun\nwallet, Electrum). From the LDK-side, a public disclosure date was proposed.\n\nStill during August 2021, the Bitcoin Core dust limit was actively\ndiscussed on the mailing list. Changes of this dust limit would have\naffected the ongoing development of the mitigations.\n\nWhile this report highlights the lack of well-defined communication process\nacross Lightning teams,  developers from 3 different implementations have\nactively participated in the vulnerabilities diagnostic and mitigations\ndevelopment of those long-standing specification issues affecting the whole\nLightning ecosystem.\n\nAll mistakes and opinions are my own and please verify any information\nreported.\n\n# Timeline\n\n* 2021-04-19: Working exploit of the vulnerability against LND,\nCL/LND/Eclair/LDK maintainers notified\n* 2021-07-21: Finding by Eugene Siegel on how to exploit the\ntrimmed-to-dust mechanism at `update_fee` reception\n* 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the lack\nof verification of counterparty per-HTLC `dust_limit_satoshis`\n* 2021-08-16: Mitigations developed in LDK, communication of a public\ndisclosure date\n* 2021-08-26: Notification to Muun wallet, non-affected\n* 2021-08-27: Notification to Electrum wallet\n* 2021-10-04: Full Disclosure of CVEs\n* 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/9af032f2/attachment.html\u003e"}