Staying Safe from the Recent Lightning Vulnerability
by Olaoluwa Osuntokun and Conner Fromknecht
A vulnerability affecting many major Lightning implementations was fully disclosed today after a partial disclosure on August 30th. For a more detailed description of how CVE-2019-12998, CVE-2019-12999, and CVE-2019-13000 affect their respective implementations, please refer to the lightning-dev mailing list.
If you run an lnd node, or have an application that runs lnd which isn’t
already on version
v0.7.1-beta, then we very strongly recommend you update in
order to prevent loss of funds. Exploiting the vulnerability requires modifying
a version of lnd. We have created
tools one can use to check if
your lnd node was targeted.
The remainder of this post will describe the general vulnerability, how to determine if your node was affected, how to remedy or mitigate the issue, and finally some preventive measures we can take to improve the overall security of the Lightning Network.
Overview of the Vulnerability
As background for this issue it’s important to understand that when a node on the Lightning Network accepts a new inbound channel, it should check that the channel actually exists and is well-formed. The vulnerability falls into a class of input validation attacks, where adversarially controlled parameters provided during channel creation are not fully validated after the channel confirms, and before channel usage begins.
Once a channel has reached the required confirmation depth, there are two things a node should verify:
1.The outpoint (txid and index pair) matches the input the signed commitment transaction references.
2.The value of the created output matches the expected size of the channel.
Failure to do so may lead to a node accepting an invalid channel. Rusty
Russell discovered that many of the major Lightning implementations were
lacking some or all of these checks, and, more importantly, how this could be
exploited. The exploit was fully patched in
July 30th 2019) and partially patched in version
v0.7.0 (released July 2nd
2019). For further details, see Rusty’s disclosure post to the lightning-dev
Of the two checks, failure to check the scriptpubkey (#1) is more disastrous,
since an attacker can costlessly open thousands of invalid channels per block.
Failure to verify the amount requires more capital on behalf of the attacker,
and is bounded by their ability to fan out UTXOs and get confirmations on
funding outputs with proper scriptpubkeys.
lnd has been protected against the
former in most cases since v0.6.0 (released April 16th 2019), though was still
vulnerable to the latter at the time of discovery (
v0.7.0 and earlier).
If a node accepts an invalid channel, loss of funds could occur if the node forwarded any payments that originated from that channel. If this happened, the victim node (that accepted the channel) would have lost an amount roughly equal to the amount of the forwarded HTLC(s). It loses this money as it cannot close the invalid channel, so they can’t realize the money they thought they received on the incoming channel in exchange for a smaller outgoing payment on the outgoing channel (amount out > amount in).
If you’re running
v0.7.1-beta and above, then you’re safe.
Detecting If You’ve Been Affected
As it’s possible that nodes in the wild may have been exploited in a hard-to-detect manner, we’ve created a simple tool that’s able to detect if your node was targeted.
Running the tool is straightforward, after you’ve compiled the program (or used the release binaries), execute:
If none of your open channels accepted an HTLC from an invalid channel, you’ll see something like the following:
2019/09/27 03:45:06 Num invalid channels found: 0 2019/09/27 03:45:06 Your node was not affected by CVE-2019-12999!
Otherwise, you’ll see a breakdown of which of your node’s channels are invalid, as well as the total possible amount of funds lost.
Mitigating Any Further Attacks
If, after running the script above, you find that your node has an invalid
channel, you can immediately forcibly remove the channel. It’s safe to remove
the channel as it cannot be closed, and none of your funds are contained in the
channel. One can remove the channel using the
abandonchannel RPC command.
This command can only be run if the running
lnd binary was compiled with the
dev tag. In order to compile your
lnd binary with the
dev tag, one can
execute the following command at a version of
v0.7.1 or greater:
make install tags=dev
lnd node has been re-built (if needed), you can drop any invalid
channels with the following command:
lncli abandonchannel --funding_txid=<txid> --output_index=index
Prevention If Unable to Update
If you are unable to update for any reason (though we strongly recommend you
update), you can prevent any new inbound channels by restarting your node with
--maxpendingchannels=0. This will prevent your node from accepting any new
inbound funding requests.
Future Security Practices
Lightning Labs take security matters very seriously, and here provide some
steps to ensure the safety of
lnd users and the Lightning Network as a whole
as we move forward.
Stay on Recent Releases
In coordinating the network upgrade, we were surprised to find many nodes running very old versions relative to the age of the software. Now is a good time to remind the community that Lightning software is still maturing—regardless of the implementation you run, keeping up with recent releases is important to ensuring nodes are protected against less severe issues that are patched on an ongoing basis.
If you operate a highly capitalized node or are otherwise likely to be a target, this should ring particularly true. At this point in the game it is best practice for all to be using a release that is at most a few months old. If you run into issues upgrading, please reach out via our LND Developer Community Slack or email for assistance.
The Lightning Network specification currently requires a hard funding limit of 16.7M satoshis, and a payment limit of 4.2M satoshis. These limits were put in place specifically to limit exposure to vulnerabilities like the CVEs disclosed today. Even with the current proposal to allow negotiation of higher limits, users should be cautious in blindly accepting or creating channels with higher limits. For now, we recommend that users continue to respect these limits.
Bug Bounties and Responsible Disclosures
As a proactive measure, Lightning Labs plans to create a formal bug bounty
program allowing third-party individuals to responsibly disclose new
vulnerabilities. We already work with several members of the community to
improve the security and reliability of
lnd under adversarial conditions, and
this will provide an opportunity for those individuals to be compensated for
their valuable contributions. Stay tuned for more information about the final
process. As always, we will continue to accept responsible disclosures via our