CVE-2018-20587 : RPC Man in the Middle due to fallback mechanism

[castarco]

First reported to us by @Gnappuraz .

Describe the bug Unit-e's RPC mechanism (inherited from Bitcoin) is able to listen through IPv4 & IPv6 addresses. When it successfully achieves binding to one of the two addresses, even if it fails with the other one, it continues working without halting nor showing any error message.

If an attacker has access to the same physical machine (for example using a different user, there's no need to use the same as used to run the node), it can spawn her own node listening to the not-used address, and acting as a client to the original node. This can lead to the situation where the original user connects accidentally to the adversarial node instead of connecting to the original one, leaking information about the used commands and their responses.

We have a CVE entry for Bitcoin and a blog article explaining the problem in more detail:

• https://nvd.nist.gov/vuln/detail/CVE-2018-20587
• https://medium.com/@lukedashjr/cve-2018-20587-advisory-and-full-disclosure-a3105551e78b

To Reproduce

• Spawn an adversarial node listening to the most commonly used address.
• Spawn the well-behaved node, it will bind to the "secondary" address because the first one is already used.
• Try to send RPC commands to the node, with high probability the commands will be sent to the adversarial node.

Potential solutions

• Stop using a fallback mechanism, and be explicit in the configuration files (or command line configuration options) about which type of address we want to use for our node. This solution mitigates the problem by removing randomness.
• Authentication+Authorization+Encryption on RPC connections: by establishing properly encrypted communication channels (where the node is also properly identified), it would be way more difficult to fool the client application. This solution probably requires some effort from security experts to ensure that we don't introduce subtle vulnerabilities.
• Introducing unix domain sockets as another mechanism to establish RPC connections (and making them the default option wherever is possible). This could be helpful because it's easier to enforce stricter permissions settings on unix domain sockets than on network sockets.

Probably all of these three options could be applied at some point, without conflicting between them. But my hunch is that 1st and 3rd would be the easiest ones to implement, and also the ones (once combined) providing the highest security.

[scravy]

If that's a CVE with bitcoin, I guess they are taking measures against it?

[castarco]

If that's a CVE with bitcoin, I guess they are taking measures against it?

I hope so, with high probability, yes. So fourth option: pull their fixes.

[scravy]

Apparently they tried and failed:

• https://github.com/bitcoin/bitcoin/pull/14968 (patch in master becoming 0.18 branch)
• https://github.com/bitcoin/bitcoin/pull/15050 (backport to 0.17, which we will merge with soon)
• they are also not to keen to talk about it: https://github.com/bitcoin-core/bitcoincore.org/pull/637

[thothd]

https://medium.com/@lukedashjr/cve-2018-20587-advisory-and-full-disclosure-a3105551e78b

2018–12–30 A complex and experimental solution to fix both issues is released in Bitcoin Knots 0.17.1.knots20181229.

We can simply track on how the issue is eventually handled in Bitcoin core since it's more production related

[cornelius]

In the blog they say that the issue is considered low risk because the scenario of running on a computer where other users have access as well is discouraged in any way. That's why there might never be a fix.

So the fifth option would be to document how to run a node securely so that it doesn't get affected by this issue.

[Gnappuraz]

I agree with @cornelius, since there is no easy fix and is not critical, it might even never be fixed. from IRC:

19:25:41 If we really wanted a blog post ... maybe instead we should have a blog post about bitcoin wallet security best practices, and this port thing could be mentioned somewhere in it. that would make sense. But alerting on this? I don't think so.

I'm in favor of solution n.1 that is the easiest and more robust probably. Not fixing it is imho quite a sloppy solution (the problem is there, hiding behind "users falling for this are dumb" is silly and leads to poor usability).