CVE-2018–20587 Advisory and Full Disclosure (Bitcoin Core & Knots, on multiuser systems)

CVE-2018–20587 is an Incorrect Access Control vulnerability that affects all currently released versions of Bitcoin Core, including the latest 0.17.1 (and probably future releases too), as well as Bitcoin Knots prior to 0.17.1.knots20181229.

You may be affected by this issue if you have the RPC service enabled (default, with the headless bitcoind), and other users have access to run their own services on the same computer (either local or remote access). If you are the only user of the computer running your node, you are not affected. If you use the GUI but have not enabled the RPC service, you are not affected.

Generally, it is not recommended to trust a computer that other users have access to, so this vulnerability is considered low risk, and may not be fixed in Bitcoin Core at all.

Note that in all cases with multiple users, attempting to use the RPC service while your node is not running may create a security risk. While your node is not running, it can do nothing to prevent this. Always ensure your node is running before you attempt to access the RPC service! Note that making another RPC call is not sufficient to safely check that it is running. (This risk is not covered by the CVE, and indeed affects all software with RPC services, not just Bitcoin nodes.)

(Also, as a reminder, please note that the RPC service should never be exposed to any untrusted network or host. Do not set “rpcbind” or “rpcallowip” to anything other than “127.0.0.1” unless you are familiar with network security and aware of the potential consequences.)

Workarounds

There are multiple ways to eliminate the risk:

• Forbid usage of your computer by other people. This includes remote access. Securing access to login to the computer is outside the scope of this advisory.
• Forbid other users of your computer from binding to the RPC port on any network interface. (How to do this is non-trivial and outside the scope of this document.)
• Turn off the RPC service, and never attempt to use it. To do this, ensure that your bitcoin.conf file includes the line “server=0”. You can confirm it has been disabled, if the bitcoin-cli program fails to execute any command, saying “Could not connect to the server”.
• Before accessing the RPC service, check that your node’s debug.log does not contain any “Binding RPC on address … failed” lines.
• Configure your node to only bind a single RPC port. To do this, make sure your bitcoin.conf contains exactly one line beginning with “rpcbind=” and at least one line beginning with “rpcallowip=”. Generally, you want to ensure these are “rpcbind=127.0.0.1” and “rpcallowip=127.0.0.1” (any other values may fail to eliminate the danger). With this configuration, the software will refuse to start unless it successfully binds the appropriate port.

You can also upgrade to Bitcoin Knots 0.17.1.knots20181229 or newer, which has an experimental fix for this issue (but only while it is running, obviously). Since this fix has not been extensively tested, you should still mitigate the vulnerability with one of the above methods, or attempt to compromise your own node as described below (if you do test the exploit, please report whether Knots’ fix does or does not work on your system to luke_bcknots_cve2018_20587@dashjr.org).

Technical Details

By default, the RPC service attempts to bind and listen for connections on both IPv4 localhost and IPv6 localhost. So long as either of these succeeds, startup is considered successful, even if the other fails.

However, this means it is possible for another user on the system to quietly bind the IPv4 localhost port, and forward requests to the IPv6 localhost port, intercepting the request, response, and authentication credentials (including both the RPC server authentication, as well as any wallet password(s) if such wallets are unlocked in this way).

The other user can then use the credentials to make his own requests, including RPC calls that may compromise consensus, send the wallet’s bitcoins elsewhere, and so on.

Timeline

• 2018–12–10 Bui Thanh, on behalf of a team of security researchers from Aalto University and University of Helsinki, reports the issue to a number of Bitcoin Core developers.
• 2018–12–13 Upon further inquiry from Bui Thanh, Matt Corallo confirms receipt of original report, and reaffirms that users have always been advised not to expose the RPC service to untrusted networks/hosts.
• 2018–12–14 Bui Thanh recommends that Bitcoin Core should not silently ignore failures to bind RPC listening ports.
• 2018–12–15 Wladimir J. van der Laan submits pull request #14968 to fix the issue.
• 2018–12–28 Due to the fix proposed in #14968 breaking the RPC service working on IPv4-only systems, and no straightforward way to resolve both issues, the fix is deferred.
• 2018–12–30 A complex and experimental solution to fix both issues is released in Bitcoin Knots 0.17.1.knots20181229.
• 2018–12–30 The vulnerability is officially assigned CVE-2018–20587.
• 2019–01–15 Proposal to disclose vulnerability and mitigations shared with other involved parties.
• 2019–01–21 David Harding submits pull request #15223 to document the issue, along with other RPC service risks in general.
• 2019–01–21 PR #15223 documenting the issue is merged into Bitcoin Core.
• 2019–02–07 At the weekly Bitcoin Core meeting, the issue is discussed and ultimately it is decided that a dedicated advisory will not be published to bitcoincore.org.
• 2019–02–08 Advisory and full disclosure is posted to Luke Dashjr’s personal blog.