<p><a href="http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_Flash" rel="nofollow">This page</a> says that a Flash applet can only access the port and hostname of the URL from which it was downloaded:</p>

<blockquote>
  <p>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. <strong>Flash applets have their security context derived
  from the URL they are loaded from</strong> (as opposed to the site that embeds
  them with  or  tags), and within this realm, <strong>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</strong>, 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.</p>
</blockquote>

<p>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.</p>

<p>I've been able to find balances using simple HTTP 'POST' requests:</p>

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

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

<p>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:</p>

<pre><code>$ i=100; while ((i&gt;0)); do ((i--)); echo $(echo $i; date;
  echo '{"method":"getbalance","params":[""]}' |
  POST http://$user:guess$i@localhost:8332/ 2&gt;&amp;1 | grep -i body);
  done; echo '{"method":"getbalance","params":[""]}' |
  POST http://$user:$pass@localhost:8332/
99 Tue Apr 24 09:10:10 PDT 2012 &lt;BODY&gt;&lt;H1&gt;401 Unauthorized.&lt;/H1&gt;&lt;/BODY&gt;
98 Tue Apr 24 09:10:10 PDT 2012 &lt;BODY&gt;&lt;H1&gt;401 Unauthorized.&lt;/H1&gt;&lt;/BODY&gt;
[...]
1 Tue Apr 24 09:10:53 PDT 2012 &lt;BODY&gt;&lt;H1&gt;401 Unauthorized.&lt;/H1&gt;&lt;/BODY&gt;
0 Tue Apr 24 09:10:53 PDT 2012 &lt;BODY&gt;&lt;H1&gt;401 Unauthorized.&lt;/H1&gt;&lt;/BODY&gt;
{"result":-6203.99412537,"error":null,"id":null}
</code></pre>

CC BY-SA 3.0
2012-04-24T05:07:29.413Z
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...
David Perry
CC BY-SA 3.0
2012-04-24T16:15:33.680Z
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
CC BY-SA 3.0
2012-04-24T17:00:16.987Z
Aaaaand I'm now heading over to github to open an issue re: RPC being brute-force-able :P
Thanks!
David Perry
CC BY-SA 3.0
2012-04-24T18:23:56.523Z
[Question answered](https://github.com/bitcoin/bitcoin/issues/1145#issuecomment-5312121): There is a forced 250ms delay between RPC logins if your RPC password is < 20 characters long.
David Perry
CC BY-SA 3.0
2012-04-24T21:46:57.117Z
My 100 attempts took 43 seconds, so that's plausible.
Chris Moore
CC BY-SA 3.0
2012-04-24T01:52:11.463Z
2012-04-24T16:14:55.567Z
2012-04-24T16:14:55.567Z
Chris Moore
<p>In <a href="https://bitcointalk.org/index.php?topic=77825" rel="nofollow">this thread</a> 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.</p>

<p>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.</p>

<security><attack>
Is an attack on a local bitcoind via an img or embedded flash viable?
David Perry
# Is an attack on a local bitcoind via an img or embedded flash viable?

(Asked by: username_0 on 2012-04-23)

In [this thread](https://bitcointalk.org/index.php?topic=77825) 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.

**Tags:** security, attack


---

## 1 answers

### Answer by username_1 on 2012-04-24. Score: 2 | Accepted answer

[This page](http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_Flash) 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}

```

> **Comments:**
> **username_0**: 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...  
> **username_1**: 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.  
> **username_0**: Aaaaand I'm now heading over to github to open an issue re: RPC being brute-force-able :P Thanks!  
> **username_0**: [Question answered](https://github.com/bitcoin/bitcoin/issues/1145#issuecomment-5312121): There is a forced 250ms delay between RPC logins if your RPC password is < 20 characters long.  
> **username_1**: My 100 attempts took 43 seconds, so that's plausible.  

---

