bitcoin-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 21, 2023 00:18 UTC
In the given email, the sender discusses an attack scenario involving the replacement of Hash Time Locked Contract (HTLC) transactions in the mempool.
The attacker, Mallory, can only replace an HTLC-timeout transaction if she is directly connected to the targeted peer via a direct channel. It is important to note that HTLC transactions are two-party contracts with the public keys of both participants hardcoded into the contract. Therefore, a third party cannot unilaterally sweep an HTLC given only a preimage.
The email emphasizes the need to establish some fundamental context. When the timelock of an HTLC expires and the receiver has knowledge of the preimage, a bidding war begins. If the receiver confirms their success transaction in time, they gain the funds, and the sender can pipeline the preimage backwards in the route. On the other hand, if the sender wins, it is as if nothing happened except for the fees paid at the last mile, and all other hops can safely cancel their HTLC on-chain.
Most implementations today monitor the mempool for preimages, allowing them to resolve incoming HTLCs off-chain quickly. The success of the attack described heavily relies on the attacker's ability to execute precise transaction replacements across "the mempool." If any honest party sees the preimage in the mempool, they can settle off-chain, and if their timeout confirms first, the defender gains funds.
To successfully execute this attack, the attacker needs to maintain precise execution for hours or even days. Within the Lightning Network (LN), nodes set a security parameter called CLTV delta, which determines the time they have before outgoing and incoming HTLCs expire. Increasing this value makes the attack more challenging as the attacker must balance low fees to avoid mining while ensuring they can replace the defender's transaction without being mined themselves.
One approach for the attacker is to locate the defender's node and launch the replacement attack directly in their mempool. However, this would reveal the preimage to the defender, allowing them to settle everything back and thwart the attack. Furthermore, the attacker needs to iteratively execute the replacement across a real network, accounting for network jitter, propagation delay, and geographic heterogeneity. Even slight timing discrepancies could result in confirmation or premature revelation of the preimage in the mempool.
For anchor channels, the defender can attach arbitrary inputs for fee bumping purposes using second-level HTLCs. They can iteratively increase their fee via Replace-by-Fee (RBF) as the expiry deadline approaches, further increasing the cost for the attacker. Additionally, the attack cannot be launched indiscriminately across the network; it requires per-node setup by the attacker, consuming UTXOs to create a chain of transactions for the replacement attack. These transactions also need to be maintained in a state of non-confirming superposition.
In summary, the attack described in the email is considered fragile, requiring per-node setup, precise timing and execution, non-confirming superposition of transactions, and instant propagation across the entire network of the replacement transaction while remaining obscured from the defender's perspective. The attack can be launched directly with a miner or "into" their mempool, but this weakens the attack as any broadcasted preimage replacement transactions can be used by the defender to extract the preimage and settle the incoming HTLC.