How Ethereum can be stolen through DNS rebinding

This is ludicrous. If a torrent client considers this class of bug to be a vulnerability[1], I don't see why folks who are trying to revolutionise money (something that is far more important than a few small RCEs) don't. While it is true you need to run it with the --rpc option, I'm confused why the RPC is unauthenticated by default, and whether there is any front-end that will start up the RPC server in the background (similar to electrum).

[1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702

This specific problem is easily mitigated. However, for most people who dabble in cryptocurrencies, they don't realize relying on security and setting defaults is just asking for trouble.

  DNS rebinding to bypass SOP is an old and known issue. There is nothing
  particular about geth being vulnerable to this.
  * The RPC api is not the primary protection against theft of ether, users are
    encouraged to have a long and difficult password, presumably difficult to
    bruteforce.
  * Although I cannot find the ticket right now, we're already considering
    being even more strict on Origin, so that geth would not accept
    POST-requests from non-whitelisted Origin:s (by default).

I'm not sure about the first bullet point. You have to unlock your accounts before calling any balance-changing methods but I don't know if there is a default time after which the accounts get locked again.

Even if there is, isn't there a time period while your accounts would be vulnerable?

As this seems easily mitigated by a simple security token, I don't see why they shouldn't implement this.

How are DNS rebinding attacks not a valid vulnerability?

This is true over http and browsers, as well as internal servers, sockets, and cross frame communication. There are no such things as trusted internal services, just services that have not yet been breached (looking at you hardware vendors).

For example in unbound there's

    private-address: <IP address or subnet>
              Give  IPv4  of  IPv6  addresses  or classless subnets. These are
              addresses on your private network, and are  not  allowed  to  be
              returned  for  public  internet  names.   Any occurrence of such
              addresses are removed from DNS answers. Additionally, the DNSSEC
              validator  may  mark  the  answers  bogus. This protects against
              so-called DNS Rebinding

The thing I’m most disappointed with is that because we’ve been so lax about 127.0.0.1 and it’s usage, it’s become a means of different applications to blackhole requests suchas ad-blocking networks.

Better than that though, are the applications that are using localhost resolution from public names to communicate with local versions of their applications from the browser.

The sad thing, is that because of these we can’t just make a simple resolution policy. The one I would like to be true is that only localhost names can resolve to localhost (this doesn’t require any remote resolution), and that you must whitelist private domains for private address spaces (e.g. 10/8). For localhost it’s a very simple area in resolution code to drop RData with 127.0.0.1, private address spaces would need a little more but still easy to identify when to apply it.

For now it seems that we have to rely on applications to do a better job of using things like TLS to validate the endpoints to which they are connecting and verifying that the IP is in the expected scope.

There are many simple solutions (force auth, xsrf token) and it is mind-boggling that these mitigations are not considered standard-issue in the space.

---

We originally rejected the bounty report because:

* We always recommend people communicate with Geth via IPC, not HTTP. The APIs are too powerful for public access: even if noone can steal your Ether, they can exhaust all your local resources via eth_call for example. Our suggestion is to always run a custom proxy that properly rate limits and authenticates outside users vs. running an HTTP server inside Geth. CORS is a protection that always depends on browsers correctly enforcing it, which have been circumvented multiple times, so it's not a good enough security measure. * For a very long time now, we considered unlocking an account a dangerous operation recommended only to power users who can properly protect their setup. Mist and other applications transact via API endpoints that do not unlock accounts, so unless a user explicitly manually unlocks their account, they should be fine.

That being said... even though we consider the attack vector fairly convoluted and would require a lot of bad user practices to pull off; we agreed that if we can do anything meaningful to prevent it, then we should most definitely do that. For that reason we introduced the `--rpcvhosts` flag which is similar to CORS, but checks the requests origin via different means, and rejects DNS rebound HTTP actions server side.

As for the original report, although we rejected the bounty request initially, we agreed that it should be rewarded with a low-impact value since we did make a software modification based on the report. Unfortunately this bounty decision is waiting for approval since the 5th of February. Not sure why it got stuck in the pipeline, we apologize for the delay.

Sounds like a normal DNS rebind, nothing that is strictly a problem of ethereum.

Routers have had the same exact problem for years and it's been partially solved by filtering DNS answers on their side.

The easiest solution, of course, would be that browsers consider the origin of any domain pointing to 127.0.0.1 different to localhost itself. Or something in that postcode/general direction.

I do think that Ethereum ought to authenticate it's JSON-RPC service, but not because of DNS rebinding.

Not so with many other firmwares.