3

In this thread on the Bitcoin forums it was suggested that a local attack on bitcoind might be possible through malformed img tags or (more likely in my opinion) through embedded flash. This also brings up the possibility of exploitation via Java et al.

Unfortunately I don't know enough about flash to determine whether it's prevented from connecting to a listening client on localhost. I would assume it's sandboxed away from anything else on the local network, but I honestly don't know if they've bothered to restrict access to localhost.

1 Answer 1

2

This page says that a Flash applet can only access the port and hostname of the URL from which it was downloaded:

Adobe Flash, a plugin believed to be installed on about 99% of all desktops, incorporates a security model generally inspired by browser same-origin checks. Flash applets have their security context derived from the URL they are loaded from (as opposed to the site that embeds them with or tags), and within this realm, permission control follows the same basic principle as applied by browsers to DOM access: protocol, host name, and port of the requested resource is compared with that of the requestor, with universal access privileges granted to content stored on local disk. That said, there are important differences - and some interesting extensions - that make Flash capable of initiating cross-domain interactions to a degree greater than typically permitted for native browser content.

But apparently that applies to the result of a request not the request itself, so it's possible a Flash applet could send a request to your bitcoind to transfer coins, but not check to see whether it worked or not. Using wallet encryption would help mitigate this.

I've been able to find balances using simple HTTP 'POST' requests:

$ echo '{"method":"getbalance","params":[""]}' | POST http://$user:$pass@localhost:8332/
{"result":-6203.99412537,"error":null,"id":null}

I don't know if it's possible using just a regular 'GET' request.

Edit: I just tried 'guessing' the wrong password 100 times in a row, and then getting it right. bitcoind didn't stop accepting guesses or slow down at all, and accepted the final correct guess:

$ i=100; while ((i>0)); do ((i--)); echo $(echo $i; date;
  echo '{"method":"getbalance","params":[""]}' |
  POST http://$user:guess$i@localhost:8332/ 2>&1 | grep -i body);
  done; echo '{"method":"getbalance","params":[""]}' |
  POST http://$user:$pass@localhost:8332/
99 Tue Apr 24 09:10:10 PDT 2012 <BODY><H1>401 Unauthorized.</H1></BODY>
98 Tue Apr 24 09:10:10 PDT 2012 <BODY><H1>401 Unauthorized.</H1></BODY>
[...]
1 Tue Apr 24 09:10:53 PDT 2012 <BODY><H1>401 Unauthorized.</H1></BODY>
0 Tue Apr 24 09:10:53 PDT 2012 <BODY><H1>401 Unauthorized.</H1></BODY>
{"result":-6203.99412537,"error":null,"id":null}
5
  • 1
    Interesting. So assuming you were using a dictionary-word RPC password and an unencrypted wallet, a Flash applet could theoretically initiate a transfer. Is there no number of bad password attempts at which Bitcion's JSON RPC will simply stop accepting requests for a while? Even without a Flash exploit, the lack of such a feature would make bitcoin's RPC utterly brute-force-able... Apr 24, 2012 at 5:07
  • It would have to guess a username as well as a password I think. I edited my answer to show that you can guess wrong 100 times without being penalised. Apr 24, 2012 at 16:15
  • Aaaaand I'm now heading over to github to open an issue re: RPC being brute-force-able :P Thanks! Apr 24, 2012 at 17:00
  • Question answered: There is a forced 250ms delay between RPC logins if your RPC password is < 20 characters long. Apr 24, 2012 at 18:23
  • My 100 attempts took 43 seconds, so that's plausible. Apr 24, 2012 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.