Is an attack on a local bitcoind via an img or embedded flash viable?

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}

Chris Moore

Posted 2012-04-23T22:33:11.460

Reputation: 13 952

1Interesting. 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... – David Perry – 2012-04-24T05:07:29.413

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. – Chris Moore – 2012-04-24T16:15:33.680

Aaaaand I'm now heading over to github to open an issue re: RPC being brute-force-able :P Thanks! – David Perry – 2012-04-24T17:00:16.987

Question answered: There is a forced 250ms delay between RPC logins if your RPC password is < 20 characters long. – David Perry – 2012-04-24T18:23:56.523

My 100 attempts took 43 seconds, so that's plausible. – Chris Moore – 2012-04-24T21:46:57.117

Is an attack on a local bitcoind via an img or embedded flash viable?

Answers