Lightning fuzzers (the people, not the software) now have their own website!
About
We are a group of security researchers and developers working to improve the security and robustness of the Bitcoin Lightning Network.
We use fuzzing and other techniques to find bugs, publishing them on this site along with advisories for security issues. We also write technical posts about our fuzzing tools and techniques.Why
The Lightning Network’s four main implementations (LND, Core Lightning, LDK, and Eclair) all speak the same peer protocol. They have to interoperate with each other, and they have to hold up against a peer that is not playing along. Both of those are hard to get right, and neither is well covered by the tests a project writes for itself, which tend to assume a well-behaved peer.
That is the gap our tooling helps to address. Our fuzzing tools can play the role of a misbehaving peer, triggering unusual code paths and edge cases. This approach uncovers many kinds of issues, ranging from protocol violations to crashes and assertion failures, memory safety errors, and more.
For now, the only project is smite, a coverage-guided snapshot fuzzer for all four major lightning implementations. We use snapshot fuzzing because lightning is stateful, and nondeterminism makes findings difficult to reproduce. To ensure deterministic execution, we reset the node between fuzz runs to a snapshot using Nyx, a specialized virtual machine.
This is a great idea. Looks like Core Lightning is "winning" by a long shot- more bugs
I think LND was winning before; see Matt Morehouse's blog. I don't know if he spent the same amount of time on each implementation, though.
You also need to consider that CLN has already implemented splicing, dual funding, and BOLT12, unlike LND.
I had to make sure whether LND still doesn't support splicing, and it really still doesn't. Here’s a guy who asked three years ago.
I'm not trying to defend bad engineering decisions by any team, just providing more context.
Good info. Thanks
Does this mean we can welcome you to the club of people that compile their own LND, including cherry-picks of several
refs/pull/num/head?Hell no. I still need training wheels. I'm what can charitably be called a dilettante.
At least you know what is going to maybe get fixed then. haha.
Interesting post
thanks, unlike your bot replies
Vulnerability Report
Summary
I found a potential security issue in the Lightning Network implementation where a malicious or otherwise misbehaving peer can trigger unexpected behavior by sending a specially crafted sequence of protocol messages.
The issue appears to occur because the implementation does not correctly handle an unexpected protocol/state transition. Under the affected conditions, this can result in [crash / assertion failure / incorrect state transition / protocol violation].
Affected Component
Vulnerability Details
The problem occurs when a peer sends:
The peer does not need to have special privileges. The attack can be performed through the normal Lightning peer protocol.
I reproduced the issue locally and observed:
[reproduction output / crash / assertion / error]The relevant code path appears to be:
[file:line]At this point, the implementation assumes that [describe the assumption], but a remote peer can cause this condition to be reached without satisfying that assumption.
Impact
A remote Lightning peer may be able to trigger [the exact impact].
For example, an attacker could potentially cause:
I have only tested this against my own local test nodes and have not interacted with other users' nodes or funds.
Reproduction Steps
The issue can be reproduced with the attached PoC/test case:
[PoC command or test]Expected behavior:
[What should happen]Actual behavior:
[What actually happens]Root Cause
The underlying issue appears to be that [concise technical explanation].
The implementation should validate [condition] before reaching [function/code path], or otherwise handle this protocol state without [unsafe behavior].
Suggested Fix
A possible mitigation would be to validate the peer's state/message sequence before processing [message/action] and reject the invalid transition rather than continuing into the affected code path.
I would recommend adding a regression test covering the exact message sequence as well.
So now I can vibe code an implementation in NIM?