Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-04 📝 Original message: > * C-lightning v0.10.2 ...
📅 Original date posted:2021-10-04
📝 Original message:
> * C-lightning v0.10.2 (CVE-2021-41593)
Thanks I was unsure about the exact version number. I'll update the CVE
quickly.
Le lun. 4 oct. 2021 à 14:16, lisa neigut <niftynei at gmail.com> a écrit :
> FYI the next version of c-lightning will contain the proposed
> `max_dust_htlc_exposure_msat` as outlined in #919
> <https://github.com/lightningnetwork/lightning-rfc/pull/919/files>;; the
> given expected vulnerabilities patch table should have reflected this.
>
> > The vulnerabilities are expected to be patched in:
> > * Eclair: v0.6.2+ (CVE-2021-41591)
> > * LND: v0.13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm writing a report to disclose specification-level vulnerabilities
>> affecting the Lightning implementations.
>>
>> The vulnerabilities are expected to be patched in:
>> * Eclair: v0.6.2+ (CVE-2021-41591)
>> * LND: v0.13.3+ (CVE-2021-41592)
>> * LDK: v0.0.102 (not released as production software yet)
>>
>> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>>
>> Those vulnerabilities can be exploited in a wide range of attacks, going
>> from fee blackmailing of node operators, burning liquidity of your
>> competing LSPs or even stealing your counterparty channel balance if you
>> avail mining capabilities. Exercise of the vulnerability revealed that a
>> majority of the balance funds can be at loss.
>>
>> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
>> exploitation and multiple insights about attacks.
>>
>> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
>> about mitigations development.
>>
>> # Problem
>>
>> The current BOLT specification only requires Alice's
>> `dust_limit_satoshis` (applied on Alice's commitment) to be under Alice's
>> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
>> selectable by Alice, she can inflate the dust limit until reaching the
>> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
>> of chan capacity).
>>
>> Any in-flight incoming HTLC under Alice's dust limit will be converted as
>> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
>> and as such they're still owned by Bob, until resolution (i.e a RAA
>> removing the HTLC from Alice's commitment). This limitation only applies
>> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
>> burned as fees. Therefore, Alice is free to inflict a substantial loss to
>> Bob funds by publishing her commitment on-chain.
>>
>> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
>> they're under Bob's threshold. Alice can also exploit from this angle by
>> circular routing HTLCs until reaching Bob's
>> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
>> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>>
>> Dust HTLC processing can be also exploited at `update_fee` reception.
>>
>> As the BOLT3's fees computation encompasses the negotiated feerate from
>> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
>> trimmed, the amount of balance at risk is a function of current mempool
>> feerates.
>>
>> The maximum of funds at risk on a counterparty commitment is:
>>
>> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
>> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
>> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
>> counterparty's `dust_limit_satoshis`)
>>
>> If the opener is also the attacker, the negotiated feerate can be
>> manipulated beyond the "honest" mempool feerates only upper bounded
>> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
>> fee-estimator). If the opener is the victim, the negotiated feerate is
>> still a safety concern in case of spontaneous mempool spikes.
>>
>> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
>> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
>> HTLC is removed. They're still at risk of the sum of the HTLCs under the
>> dust limit being maliciously burned.
>>
>> # Solution
>>
>> A first mitigation is to verify the counterparty's announced
>> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
>> reception and reject if it's estimated too large (see #894)
>>
>> For LDK, we choose the value of 660 satoshis as it's beyond the highest
>> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
>> safety. Propagation of Lightning time-sensitive transactions shouldn't be
>> affected.
>>
>> A second mitigation is to define a new configurable limit
>> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
>> HTLC.
>>
>> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged
>> this value as a substantial loss for our class of users. Setting this too
>> low may prevent the sending or receipt of low-value HTLCs on high-traffic
>> nodes. A node operator should fine-tune this value in function of what
>> qualifies as an acceptable loss.
>>
>> We would like to ensure that the node isn't suddenly exposed to
>> significantly more trimmed balance if the feerate increases when we have
>> several HTLCs pending which are near the dust limit.
>>
>> To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
>> the maximum of either 2530 sats per kWU or 125% of the current
>> `feerate_per_kw` (implementation-defined values).
>>
>> Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to
>> the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should be failed once it's committed.
>>
>> Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the
>> counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should not be sent and fail without forwarding.
>>
>> The check symmetry must also be applied on holder commitment
>> transactions. See PR #919 for more details.
>>
>> A last mitigation is ensuring that at `update_fee` reception, the pending
>> `dust_balance` at the new proposed feerate isn't superior to
>> `max_dust_htlc_exposure_msat`.
>>
>> # Background
>>
>> The dust limit is a base layer policy stopping the relay of a transaction
>> if one of its outputs is under a given threshold. The goal of this policy
>> is to prevent the pollution of the UTXO set with low-value outputs and as
>> such increase the amount of work done by full-nodes.
>>
>> Lightning commitment transactions should be able to propagate at any
>> point during the channel lifetime to unilaterally enforce on-chain a
>> balance. A Lightning commitment transaction with one of its outputs below
>> the dust limit would fail to relay and thus jeopardizes funds safety.
>>
>> To prevent this, BOLT2 requires counterparties to announce a
>> `dust_limit_satoshis` during channel opening (at
>> `open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must
>> be under the same party's `channel_reserve_satoshis`. This value is static
>> for the channel lifetime.
>>
>> During commitment signatures exchange, each counterparty's limit is
>> applied on each counterparty's commitment (e.g A's `dust_limit_satoshis` is
>> applied on A's commitment, though both A and B have to generate and sign
>> the transaction). An output below this limit is trimmed to fees and won't
>> materialize on the commitment.
>>
>> The specification didn't require that the `open_channel`/`accept_channel`
>> receiver verify that the announced `dust_limit_satoshis` isn't too large.
>>
>> The specification didn't require that the sum of the dust HTLC committed
>> as fees was verified against an upper bound.
>>
>> # Discovery
>>
>> Vulnerabilities around our dust HTLC processing have been known for years
>> by some LN developers/researchers.
>>
>> During Q1 2019, private discussions on the Rust-Lightning-side (LDK
>> before marketing rebranding) about potential safety risks around dust HTLC
>> processing.
>>
>> In November 2019, Rusty Russell (c-lightning) opened an issue against the
>> specification mentioning the lack of check of counterparty's dust limit
>> (#696).
>>
>> In May 2020, I published a high-level attack scenario "Miners Dust
>> Inflation attacks on Lightning Network", leveraging this lack.
>>
>> In February 2021, I did a test of the first vulnerability against LND
>> software and successfully burnt the majority of the targeted node balance
>> in fees. As it sounds to me like a check missing in the specification, I
>> notified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed
>> on the LDK-side.
>>
>> In July 2021, in the context of `option_dusty_htlcs_uncounted`
>> discussions, Eugene Spiegel (LND) reported on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception. Discussions followed
>> on the best way to mitigate this new vector.
>>
>> During August 2021, mitigations were developed and released on the
>> LDK-side. vulnerabilities were disclosed to other Lightning projects (Muun
>> wallet, Electrum). From the LDK-side, a public disclosure date was proposed.
>>
>> Still during August 2021, the Bitcoin Core dust limit was actively
>> discussed on the mailing list. Changes of this dust limit would have
>> affected the ongoing development of the mitigations.
>>
>> While this report highlights the lack of well-defined communication
>> process across Lightning teams, developers from 3 different
>> implementations have actively participated in the vulnerabilities
>> diagnostic and mitigations development of those long-standing specification
>> issues affecting the whole Lightning ecosystem.
>>
>> All mistakes and opinions are my own and please verify any information
>> reported.
>>
>> # Timeline
>>
>> * 2021-04-19: Working exploit of the vulnerability against LND,
>> CL/LND/Eclair/LDK maintainers notified
>> * 2021-07-21: Finding by Eugene Siegel on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception
>> * 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the
>> lack of verification of counterparty per-HTLC `dust_limit_satoshis`
>> * 2021-08-16: Mitigations developed in LDK, communication of a public
>> disclosure date
>> * 2021-08-26: Notification to Muun wallet, non-affected
>> * 2021-08-27: Notification to Electrum wallet
>> * 2021-10-04: Full Disclosure of CVEs
>> * 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/7a56a20b/attachment-0001.html>;
📝 Original message:
> * C-lightning v0.10.2 (CVE-2021-41593)
Thanks I was unsure about the exact version number. I'll update the CVE
quickly.
Le lun. 4 oct. 2021 à 14:16, lisa neigut <niftynei at gmail.com> a écrit :
> FYI the next version of c-lightning will contain the proposed
> `max_dust_htlc_exposure_msat` as outlined in #919
> <https://github.com/lightningnetwork/lightning-rfc/pull/919/files>;; the
> given expected vulnerabilities patch table should have reflected this.
>
> > The vulnerabilities are expected to be patched in:
> > * Eclair: v0.6.2+ (CVE-2021-41591)
> > * LND: v0.13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm writing a report to disclose specification-level vulnerabilities
>> affecting the Lightning implementations.
>>
>> The vulnerabilities are expected to be patched in:
>> * Eclair: v0.6.2+ (CVE-2021-41591)
>> * LND: v0.13.3+ (CVE-2021-41592)
>> * LDK: v0.0.102 (not released as production software yet)
>>
>> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>>
>> Those vulnerabilities can be exploited in a wide range of attacks, going
>> from fee blackmailing of node operators, burning liquidity of your
>> competing LSPs or even stealing your counterparty channel balance if you
>> avail mining capabilities. Exercise of the vulnerability revealed that a
>> majority of the balance funds can be at loss.
>>
>> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
>> exploitation and multiple insights about attacks.
>>
>> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
>> about mitigations development.
>>
>> # Problem
>>
>> The current BOLT specification only requires Alice's
>> `dust_limit_satoshis` (applied on Alice's commitment) to be under Alice's
>> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
>> selectable by Alice, she can inflate the dust limit until reaching the
>> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
>> of chan capacity).
>>
>> Any in-flight incoming HTLC under Alice's dust limit will be converted as
>> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
>> and as such they're still owned by Bob, until resolution (i.e a RAA
>> removing the HTLC from Alice's commitment). This limitation only applies
>> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
>> burned as fees. Therefore, Alice is free to inflict a substantial loss to
>> Bob funds by publishing her commitment on-chain.
>>
>> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
>> they're under Bob's threshold. Alice can also exploit from this angle by
>> circular routing HTLCs until reaching Bob's
>> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
>> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>>
>> Dust HTLC processing can be also exploited at `update_fee` reception.
>>
>> As the BOLT3's fees computation encompasses the negotiated feerate from
>> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
>> trimmed, the amount of balance at risk is a function of current mempool
>> feerates.
>>
>> The maximum of funds at risk on a counterparty commitment is:
>>
>> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
>> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
>> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
>> counterparty's `dust_limit_satoshis`)
>>
>> If the opener is also the attacker, the negotiated feerate can be
>> manipulated beyond the "honest" mempool feerates only upper bounded
>> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
>> fee-estimator). If the opener is the victim, the negotiated feerate is
>> still a safety concern in case of spontaneous mempool spikes.
>>
>> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
>> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
>> HTLC is removed. They're still at risk of the sum of the HTLCs under the
>> dust limit being maliciously burned.
>>
>> # Solution
>>
>> A first mitigation is to verify the counterparty's announced
>> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
>> reception and reject if it's estimated too large (see #894)
>>
>> For LDK, we choose the value of 660 satoshis as it's beyond the highest
>> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
>> safety. Propagation of Lightning time-sensitive transactions shouldn't be
>> affected.
>>
>> A second mitigation is to define a new configurable limit
>> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
>> HTLC.
>>
>> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged
>> this value as a substantial loss for our class of users. Setting this too
>> low may prevent the sending or receipt of low-value HTLCs on high-traffic
>> nodes. A node operator should fine-tune this value in function of what
>> qualifies as an acceptable loss.
>>
>> We would like to ensure that the node isn't suddenly exposed to
>> significantly more trimmed balance if the feerate increases when we have
>> several HTLCs pending which are near the dust limit.
>>
>> To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
>> the maximum of either 2530 sats per kWU or 125% of the current
>> `feerate_per_kw` (implementation-defined values).
>>
>> Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to
>> the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should be failed once it's committed.
>>
>> Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the
>> counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the
>> `dust_buffer_feerate`. If the `amount_msat` plus the
>> `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
>> the HTLC should not be sent and fail without forwarding.
>>
>> The check symmetry must also be applied on holder commitment
>> transactions. See PR #919 for more details.
>>
>> A last mitigation is ensuring that at `update_fee` reception, the pending
>> `dust_balance` at the new proposed feerate isn't superior to
>> `max_dust_htlc_exposure_msat`.
>>
>> # Background
>>
>> The dust limit is a base layer policy stopping the relay of a transaction
>> if one of its outputs is under a given threshold. The goal of this policy
>> is to prevent the pollution of the UTXO set with low-value outputs and as
>> such increase the amount of work done by full-nodes.
>>
>> Lightning commitment transactions should be able to propagate at any
>> point during the channel lifetime to unilaterally enforce on-chain a
>> balance. A Lightning commitment transaction with one of its outputs below
>> the dust limit would fail to relay and thus jeopardizes funds safety.
>>
>> To prevent this, BOLT2 requires counterparties to announce a
>> `dust_limit_satoshis` during channel opening (at
>> `open_channel`/`accept_channel` exchange). This `dust_limit_satoshis` must
>> be under the same party's `channel_reserve_satoshis`. This value is static
>> for the channel lifetime.
>>
>> During commitment signatures exchange, each counterparty's limit is
>> applied on each counterparty's commitment (e.g A's `dust_limit_satoshis` is
>> applied on A's commitment, though both A and B have to generate and sign
>> the transaction). An output below this limit is trimmed to fees and won't
>> materialize on the commitment.
>>
>> The specification didn't require that the `open_channel`/`accept_channel`
>> receiver verify that the announced `dust_limit_satoshis` isn't too large.
>>
>> The specification didn't require that the sum of the dust HTLC committed
>> as fees was verified against an upper bound.
>>
>> # Discovery
>>
>> Vulnerabilities around our dust HTLC processing have been known for years
>> by some LN developers/researchers.
>>
>> During Q1 2019, private discussions on the Rust-Lightning-side (LDK
>> before marketing rebranding) about potential safety risks around dust HTLC
>> processing.
>>
>> In November 2019, Rusty Russell (c-lightning) opened an issue against the
>> specification mentioning the lack of check of counterparty's dust limit
>> (#696).
>>
>> In May 2020, I published a high-level attack scenario "Miners Dust
>> Inflation attacks on Lightning Network", leveraging this lack.
>>
>> In February 2021, I did a test of the first vulnerability against LND
>> software and successfully burnt the majority of the targeted node balance
>> in fees. As it sounds to me like a check missing in the specification, I
>> notified CL/LND/Eclair/LDK maintainers. Mitigations started to be developed
>> on the LDK-side.
>>
>> In July 2021, in the context of `option_dusty_htlcs_uncounted`
>> discussions, Eugene Spiegel (LND) reported on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception. Discussions followed
>> on the best way to mitigate this new vector.
>>
>> During August 2021, mitigations were developed and released on the
>> LDK-side. vulnerabilities were disclosed to other Lightning projects (Muun
>> wallet, Electrum). From the LDK-side, a public disclosure date was proposed.
>>
>> Still during August 2021, the Bitcoin Core dust limit was actively
>> discussed on the mailing list. Changes of this dust limit would have
>> affected the ongoing development of the mitigations.
>>
>> While this report highlights the lack of well-defined communication
>> process across Lightning teams, developers from 3 different
>> implementations have actively participated in the vulnerabilities
>> diagnostic and mitigations development of those long-standing specification
>> issues affecting the whole Lightning ecosystem.
>>
>> All mistakes and opinions are my own and please verify any information
>> reported.
>>
>> # Timeline
>>
>> * 2021-04-19: Working exploit of the vulnerability against LND,
>> CL/LND/Eclair/LDK maintainers notified
>> * 2021-07-21: Finding by Eugene Siegel on how to exploit the
>> trimmed-to-dust mechanism at `update_fee` reception
>> * 2021-08-11: BOLT PR #894 opened by Bastien Teinturier, covering the
>> lack of verification of counterparty per-HTLC `dust_limit_satoshis`
>> * 2021-08-16: Mitigations developed in LDK, communication of a public
>> disclosure date
>> * 2021-08-26: Notification to Muun wallet, non-affected
>> * 2021-08-27: Notification to Electrum wallet
>> * 2021-10-04: Full Disclosure of CVEs
>> * 2021-10-04: Submit BOLT PR #919 covering the remaining vulnerabilities
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/7a56a20b/attachment-0001.html>;