lightning-dev
Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Posted on: October 17, 2023 17:47 UTC
The email discusses the possibility of a potential attack on channels in the Lightning Network (LN) that have high capacity and loose channel policies.
The sender mentions that they have not observed such an attack on the mainnet, but they have conducted demo attacks in restricted development circles to experiment with different scenarios.
The risk of exposure exists if an attacker targets channels with high capacity and loose channel policies. There is no way to configure the cap for the total value of outbound HTLC (Hash Time Locked Contract) in-flight, which is the flow affected. To observe the existence of such an attack, one can monitor mempool logs and look for a systematic conflict between HTLC timeout and HTLC preimage sequences.
The sender clarifies that this attack is not akin to a pinning attack, as it does not involve "honest" or "malicious" transactions pinned in network mempools. It can occur without network mempool congestion. The attack involves controlling two neighboring nodes to target a victim. By cycling the attack on the tail side and delaying the confirmation of the HTLC timeout covenant, the peer at the front of the victim's channel will force-close the channel and claim their timeout-path, canceling back the initial HTLC amount to the attacker's initial node.
The sender suggests that this behavior is worthy of testing and mentions a race between the victim and the attacker on the tail side, making the attack even more costly. They also discuss the implementation of Local-mempool preimage monitoring by Eclair and LND as a mitigation against old school pinning attacks. However, Core-Lightning or LDK have not implemented this mechanism yet.
In terms of defense, the sender proposes aggressively fee-bumping the HTLC-output and claiming it on the incoming side if the preimage is visible. This is only feasible with anchor channels where fees can be added to the HTLC-covenant. The sender suggests that this defensive fee mitigation would make the attack more costly for a peer, especially if fees up to 50% of the HTLC value are used. By cycling this process multiple times, the attacker would be at a heavy loss trying to steal the HTLC.
The email ends abruptly and does not include a farewell message.