Skip to content

LNbits improperly handles potential network and payment failures when using Eclair backend

High severity GitHub Reviewed Published Jun 14, 2024 in lnbits/lnbits

Package

pip lnbits (pip)

Affected versions

< 0.12.6

Patched versions

0.12.6

Description

Summary

Paying invoices in Eclair that do not get settled within the internal timeout (about 30s) lead to a payment being considered failed, even though it may still be in flight.

Details

Using blocking: true on the API call will lead to a timeout error if a payment does not get settled in the 30s timeout with the error: Ask timed out on [Actor[akka://eclair-node/user/$l#134241942]] after [30000 ms]. Message of type [fr.acinq.eclair.payment.send.PaymentInitiator$SendPaymentToNode]. A typical reason for AskTimeoutException is that the recipient actor didn't send a reply.
https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L138

This is considered a payment failure by parts of the code, and assumes the payment is not going to be settled after:
https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L144
https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L141
https://github.com/lnbits/lnbits/blob/c04c13b2f8cfbb625571a07dfddeb65ea6df8dac/lnbits/wallets/eclair.py#L146

The best way to fix this is to check the payment status after an error, and when not sure, always consider a payment still in flight.

PoC

A very simple way to exploit this is:

  • Create a hold invoice
  • Pay the invoice with the LNbits server backed by an Eclair node, until it times out
  • Settle the hold invoice

Impact

This vulnerability can lead to a total loss of funds for the node backend.

References

@motorina0 motorina0 published to lnbits/lnbits Jun 14, 2024
Published by the National Vulnerability Database Jun 14, 2024
Published to the GitHub Advisory Database Jun 17, 2024
Reviewed Jun 17, 2024

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

EPSS score

0.043%
(10th percentile)

Weaknesses

CVE ID

CVE-2024-34694

GHSA ID

GHSA-3j4h-h3fp-vwww

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.