Staying Safe from the Recent Lightning Vulnerability

in security

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 lnd version v0.7.1 (released 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 mailing list.

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 lnd version 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:

./chanleakcheck

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 lncli 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 lnd v0.7.1 or greater:

make install tags=dev

Once your 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.

Channel Limits

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 security email.