Possible bug 0.9.2.1 bitcoind - rpc port 8332 available to everyone.

[TheFootMan]

Software: Non-altered 64-bit linux binary 0.9.2.1 bitcoind verified sha256sum and checked that the sha256sum file had a legit pgp signature.

Content of bitcoin.conf:

Code:

server=1
rpcuser=user
rpcpassword=pass
rpcallowip=127.0.0.1
logtimestamps=1
alertnotify=echo %s | mail -s "Bitcoin Alert" alert@domain.com
maxconnections=5

Bitcoind is started with:

Code:

bitcoind -daemon

With the above configuration, a portmap scan from another machine revealed:

Code:

nmap -v4 -Pn -p 8332 ipofbitcoinnode
8332/tcp open  unknown

I then altered the config file, shut down and restarted the bitcoin node:

Code:

rpcuser=user
rpcpassword=pass
logtimestamps=1
alertnotify=echo %s | mail -s "Bitcoin Alert" alert@domain.com
maxconnections=5

Code:

$ nmap -v4 -Pn -p 8332-8333 ipofbitcoinnode
PORT     STATE  SERVICE
8332/tcp closed unknown
8333/tcp open   unknown

The question is: In the first configuration, should not rpc-port 8332 only be accessible to localhost (127.0.0.1) and all others be blocked by default? I can't see a rpcdisallowip or similar configuration flag exist. And it seems that setting server=1 overrides rpcallowip=127.0.0.1?

I think that for security reasons, when server=1 is set in bitcoin.conf or given on the command line as -server when starting bitcoind, who can connect to the node should be explicitly needed to configured. For example by introducing a new parameter like rpcdisallowip.

When server=1 i propose that the following should hold true:

rpcdisallowip by default is set to ALL as in 'Deny All'
rpcallowip by default is set to 127.0.01, localhost. (perhaps also bitcoind upon start should print a warning if server=1 explaining that rpc server is active, and that it only accepts connections from localhost, and you need to use the rpcdisallowip and rpcallowip config settings to alter the default behaviour.

The reason I think this is important, is that someone not too experienced might set server=1 and rpcallowip=127.0.0.1 in their bitcoin.conf, and think they're all good to go, while in reality they've opened up themselves to the entire internet.

I think that rpcallowip should override rpcdisallowip.

Example:

Code:

rpcdisallowip=ALL
rpcallowip=127.0.0.1,222.222.222.222

It should mean that only 127.0.0.1 and 222.222.222.222 can connect to rpc port 8332.

 (but perhaps it would be smarter to do it the other way around, so that you always was sure that if you disallowed some ip, that would always be the authoritative setting? Not sure what the best practice here is. But I guess other software like apache, sshd etc. already has this pretty much figured out.

The problem is though if rpcdisallowip is authorative and sett to ALL, then no matter what you did with rpcallowip would have any effect, so the best thing I would think would be to see how other established open source projects has solved rule based access.

However, I might be completely off with my thinking, and this being a complete non-issue, so I'm interested in seeing what others think of this. But currently, how do you prevent everybody from accessing port 8332 when setting server=1 and there being no BLOCK ALL default rule? I can see using iptables or other software to set rules, but I do think it should be possible to set this in bitcoind.

[DeathAndTaxes]

server=1 doesn't override rpcallowip settings.  server=1 has no effect on bitcoind at all.  It is only used by bitcoin-qt to allow rpc calls against that application.    There is no need for an rpcdisallow setting because by default all remote addresses are blocked unless explicitly added via rpcallow.  

I believe the remote port scan is just showing access through the firewall.  It doesn't mean that bitcoind is responding (or even will respond).  

To demonstrate I shutdown bitcoind and manually punched a hole in the firewall.  nmap shows

Starting Nmap 6.45 ( http://nmap.org ) at 2014-07-08 04:44 Central Europe Daylight Time
Nmap scan report for nope (nope)
Host is up (0.17s latency).
PORT STATE SERVICE
8332/tcp open unknown
8333/tcp open bitcoin
Nmap done: 1 IP address (1 host up) scanned in 1.08 seconds

Have you tried executing an RPC command remotely to verify that you can in fact reach bitcoind from a remote IP address.  My guess is you will not get a response from bitcoind from the remote ip address but will from the local machine.  If you want added security against a misconfiguration then explicitly close the port in the firewall.

[TheFootMan]

server=1 doesn't override rpcallowip settings.  server=1 has no effect on bitcoind at all.  It is only used by bitcoin-qt to allow rpc calls against that application.    There is no need for an rpcdisallow setting because by default all remote addresses are blocked unless explicitly added via rpcallow.  

In the first configuration in the OP, i tried to issue rpc commands from external ip, and received "error: server returned HTTP error 403", so you are correct.

My question then becomes: When bitcoind starts and reads server=1 and rpcallowip=127.0.0.1, why should it open the port to the world, should this not only listen on 127.0.0.1? It seems that changes to bitcoin.conf are only read when bitcoind is starting,  so changes to it requires a restart of bitcoind, so if you add rpcallowip=222.222.222.222, would not the correct behaviour be that bitcoind then started to listen to other network interfaces?

To sum it up: There should be no need for bitcoind to have 8332 open and announced to the world when it is not accepting outside connections?

I believe the remote port scan is just showing access through the firewall.  It doesn't mean that bitcoind is responding (or even will respond).  

That is correct.

I am  aware of the fact that I can configure the firewall to set rules which I prefer, I was more concerned about port 8332 being open here by default by bitcoind, listening to all network interfaces, after all, when it is open, cannot an attacker try out various ways of 'exploiting' it, and also, you're announcing that this machine does in fact have 8332 open, so attackers might run automatic tools that will do probing, and eventually they will get into a misconfigured box, but maybe having port 8333 open already announces the same, so that my argument becomes a moot point?

[DeathAndTaxes]

I am  aware of the fact that I can configure the firewall to set rules which I prefer, I was more concerned about port 8332 being open here by default by bitcoind, listening to all network interfaces, after all, when it is open, cannot an attacker try out various ways of 'exploiting' it, and also, you're announcing that this machine does in fact have 8332 open, so attackers might run automatic tools that will do probing, and eventually they will get into a misconfigured box, but maybe having port 8333 open already announces the same, so that my argument becomes a moot point?

Good point. Honestly I never noticed because I always configure my firewalls as closed by default and only explicitly open ports as needed.   Your right the port should appear closed (or actually not respond at all).  If you have the skills make it so and put it into a pull request.

[TheFootMan]

I am  aware of the fact that I can configure the firewall to set rules which I prefer, I was more concerned about port 8332 being open here by default by bitcoind, listening to all network interfaces, after all, when it is open, cannot an attacker try out various ways of 'exploiting' it, and also, you're announcing that this machine does in fact have 8332 open, so attackers might run automatic tools that will do probing, and eventually they will get into a misconfigured box, but maybe having port 8333 open already announces the same, so that my argument becomes a moot point?

Good point. Honestly I never noticed because I always configure my firewalls as closed by default and only explicitly opened.   Your right the port should appear closed.  If you have the skills make it so and put it into a pull request.

To be honest, I do feel I am nitpicking a bit here, and as much as I am right, I do not feel that this is an important issue to work on. I do some coding, but to be honest, it would be a lot of work for me to pull this off, whereas someone very familiar with bitcoind probably could pull it off in an hour or two, I would probably use a lot more time to make it happen, time which I rather should spend on other stuff.

I think the most important point is that the 'bug' i was talking about was not actually a very serious bug in my view, but rather a very minor issue, that easily can be avoided by configuring the firewall properly. What I could do however, was to file a bug-report explaining the issue, and see if anybody else has the skill to solve it rather easily and submit a pull request (heck i am even unfamiliar with that concept - but i assume it's about downloading the source code, then work with that until you are happy, and then submit the diff as a pull request, and then if you are lucky, it gets accepted and included in the official bitcoind client, so everyone can see your name on the contribution list, except that for me a nickname would be better, as i really don't think getting my name out there is important, i am not a particular vain person, and i am not seeking recognition even if i had the skillset and knowledge to make really important contributions, i think i would still prefer to go by nickname only.

So, should this issue be submitted, is it important enough for that, or should it just be left alone, as it's no big deal? Is having the port 8332 open when the user has intended it not to be, really a big problem? I am not a network expert, but could potentially someone find a flaw and send malicious packets, or a specially crafted query to that port and somehow cause a ddos or achieve privilege escalation, or is that a completely non-issue? From my point of view, I just think that the port should not be announced to the world unless the user specifically wants it to do so, and when the user only wants to accept rpc-commands from localhost, then i do think bitcoind should only listen to localhost.

[gmaxwell]

There is an option to control binding separately from access:

  -rpcbind=<addr>        Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)


If you don't set an rpcallowip at all the default is that only 127.0.0.1 is allowed _and_ it only binds to 127.0.0.1. So if you just leave out your redundant allow statement you'll get what you want.   It would probably be prudent to detect rpcallowip=127.0.0.1 and also bind only to localhost in that case— it doesn't matter, but it would avoid false alarms like yours.

Edit: After looking into making the change, I think that detecting localhost is too complex to be worth it. (e.g. correctly detecting 127.0.0.0/8 vs 127.0.0.0/1)

[coinsolidation]

was there not some discussion of having bitcoin bind to a random port on the specified interface(s) rather than the default port? did anything ever happen in this regard.

I think that rpcallowip should override rpcdisallowip.

agree, whitelist rather than blacklist, easier to maintain.

[DeathAndTaxes]

was there not some discussion of having bitcoin bind to a random port on the specified interface(s) rather than the default port? did anything ever happen in this regard.

This is about RPC.  There would be no point to bind RPC to a random port.  The question is should it be responding to requests from ip addresses which aren't part of the rpcallow (which by default is 127.0.0.1).  It doesn't give access but it does respond with an error message which is not optimal.  From a network security standpoint no information leakage is optimal.  Most firewalls don't even respond that a port is closed, they just don't respond period (by dropping the offending packets).  This gives the attacker less information.   If bitcoind rpc is only allowed to "talk" to 127.0.0.1 then it should just drop packets from any other ip address rather than respond externally with an error.