Author: Antoine Riard 2020-09-13 23:29:59
Published on: 2020-09-13T23:29:59+00:00
In a recent post, Antoine Riard has highlighted a potential vulnerability in the Lightning Network's anchor output spec update. The vulnerability is related to the new usage of SIGHASH_SINGLE for HTLC transactions and how it can be harmful to fund safety. Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for HTLC signatures sent to the counterparty. This enables the single-party to bump the feerate of 2nd-stage HTLC transactions without counterparty cooperation, making HTLC funds safer. However, by increasing the feerate using update_fee, a malicious party can inflate fees committed on HTLC input/output pairs and redirect this inflated fee to a single-controlled output attached to these malleable pairs.Olaoluwa Osuntokun suggests a simpler mitigation for non-initiators to reject unreasonable update_fee proposals. The non-initiator can run a "fee leak calculation" to compute the worst-case leakage of fees in the revocation case. However, there isn't a way to do a "soft reject" of an update_fee as of now. Implementations can start to phase out usage of update_fee by setting a minimal commitment fee when the channel is first opened, then relying on CPFP to bump up the commitment and any HTLCs if needed. Johan Torås Halseth plans to phase out update_fee in favor of only accepting the minimum relay fee (zero fee if/when package relay is a reality). Johan is open to patching the spec to disallow update_fee for anchor channels but suggests adding a warning and discouraging it. If an attacker cannot impact the intended miner fees on the HTLCs, then it should mitigate the attack completely, as it could only siphon off the minimal miner fee if anything at all. In the mid-term, future iterations of dynamic commitments may allow us to update them on the fly.The post describes a vulnerability in the Lightning Network that enables an attacker to steal funds from an LN channel. The vulnerability is due to the use of anchor outputs, which allow for the creation of multiple HTLCs with a single transaction. The attacker can exploit this by spending their own revoked commitment transaction while bypassing the revocation punishment and then spending the victim's HTLCs. The absolute fee committed by the attacker at each stage is also mentioned, including the amount paid as miner fees in case Alice needs to timeout HTLC on-chain.The post details how Alice can escape from the attack and take advantage of the situation by sending a HTLC relayed by Bob either to a colluding channel on the rest of the network or back to an on-chain address thanks to a swap service. Alice finalizes HTLC-timeout of state N by capturing almost all of the absolute fee to a new P2WPKH output only controlled by her. After confirmation and thus maturing of the CSV of 1 on her HTLC output, Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to pay a low-fee. The limitations of the attacker's success are discussed, such as the fact that post-anchor HTLC outputs are CSV'ed by 1, which means in theory, an honest party can punish this output before the malicious spend them with the revoked HTLC txn. Other limitations include the per-implementation channel policy `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and acceptance bound of `update_fee`.The post suggests countermeasures that can be taken against this vulnerability, such as tighter channel policies, patching current anchor spec to remove `feerate_per_kw` appliance on 2nd-stage transactions, and adopting a scorched earth approach binding their feerate to the max to increase odds of winning the feerate race and thus deter attackers. The post concludes by inviting further thoughts on countermeasures and any missing details in the vulnerability description.
Updated on: 2023-06-03T02:09:54.304529+00:00