Disclosure: Critical vulnerabilities fixed in LND 0.19.0

[morehouse]

@ariard

Thanks for the disclosures – Browsed over the Replacement Stalling Attacks one, if my memory is correct on this subject, I think Bastien Teinturier was the first back in 2021 sharing with few lightning devs the idea of “cat-and-mouse” attacks, i,e adversarially aggregating and disaggregating option_anchors second-stage HTLCs transactions. Sounds what you found is one variant of those “cat-and-mouse” attacks, but this is nothing very specific to LND.

The general weakness in LND was that transaction fees could be manipulated to stay too low, and the reaggregation+rebroadcast period was infrequent (once every two blocks). As a result, an attacker could pull off the attack for cheap. At the time I looked at other implementations and found their fees couldn’t be manipulated this way, and they generally responded to double spends immediately after confirmation. But I think there certainly is much that can be improved about other implementations’ fee bumping strategies to protect against replacement cycling and similar attacks in general.

About disclosure timeline, 90-days is generally the basic infosec embargo timeline. It can be a bit dry, assuming it’s a “simple” bug that can be fixed solely by the implementation (so no cross-layer vulnerability), letting a 4-6 months sounds more generous and in line with the usual release cycles of Lightning implementations. It’s really depends on the type of vulnerability, however the drawback with an isolated release with only 2 or 3 lines of changelog, with one altering some critical code paths, is to make it too much obvious there is “covert fix” somewhere and lowering the bar for any external actor to know what to look for to reverse-engineer.

Yes, though 90 days may be a bit aggressive when so much money is at risk. Especially for LND, which has historically had a lot of upgrade friction. Perhaps 6 months is a better disclosure timeline.

On all the logic area you’re pointing you, i.e claimable outputs detection, generation of claims transactions, fee selection and scheduled rebroadcast of the claims of transactions, it has been floated few times the idea, at least since 2020, to write a specific BOLT encompassing all this flow with the do and don’t. While there is no necessity at all of inter-compatibility among the Lightning implementations on logic, despite being one of the most critical area for channels funds security, somehow Lightning implementations kept put one’s foot in one’s mouth on this flow. An (incomplete) experience has been attempted for the DLC spec on what such piece of recommendations can cover.

Perhaps this would be beneficial. I’ve also long thought that LN implementations are barking up the wrong tree with all these force close fee optimizations. Getting too fancy in this area inevitably leads to vulnerabilities. Perhaps we should focus on making force closes less frequent (e.g., by reducing state machine bugs, implementing 0-fee commitments) rather than saving ~30% or less on fees by batching.