> PS: This has been reported to the ethereum foundation but they don’t consider it a valid vulnerability.
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).
This type of mentality is very pervasive in ethereum culture. They built their scripting language with this mentality. They chose to have multiple clients with this mentality. They designed their 12 second blocks with this mentality.
That's why a lot of the more technical people really dislike ethereum. It's not one or two problems. The entire system all the way through want made with the mentality of compromising stability in favor of getting features sooner.
The downsides of Ethereum is discouraging me a bit from developing on their platform. Then again they are the biggest smart contract crypto currency, but maybe it could be worth to build things with another one even so. Could you recommend some with good technical foundations that are ready for use today and with enough documentation that it’s possible to understand? I know Ark plan to but as far as I am aware they have not yet implemented smart contracts. NEO on the other hand I know supports smart contracts today and some different languages. Don’t know what actually building something with NEO is like though. Any one have experience with NEO? Any other crypto currencies with smart contracts?
I'm old to the thread but I figured I would bring some arguments against ranking this vulnerability as a high severity one for geth:
* This is a "browser bypass of SOP" issue. All your "unauthenticated" local services should be vulnerable.
* A good part of Geth's usage is for servers that do not browse the internet.
* You usually do not handle accounts inside of a geth node, instead you open the node's API via RPC and have another tool that sends already-signed transactions to it. That means that this attack would probably not yield much if not allow someone to use the geth node as a public node to query public information.
* If you do decide to handle accounts in there, you would probably (1) not open the node with RPC and (2) have the accounts be encrypted. See Ethereum's documentation[1] :
> It supports interactive mode, when you are prompted for password as well as non-interactive mode where passwords are supplied via a given password file. Non-interactive mode is only meant for scripted use on test networks or known safe environments.
I very much doubt that torrent client authors consider this to be a vulnerability in their client, but they fixed it anyway because they prefer to work around browsers being weird than to leave all their users vulnerable. I suspect this will eventually be the position of the Ethereum Foundation, but who knows.
I once lost bitcoins in my Mt Gox account when I clicked on a dodgy popup while logged into my account.
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.
On Reddit ret2got quoted the EF on why they don't consider this a geth vulnerability:
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.
Yes, the same-origin policy is just meant to prevent one website from accessing/using the cookies of another website. It is not designed to prevent web applications from accessing network resources.
Having a service accepting commands with no authorization is a vulnerability. If there are multiple users on the machine they can empty each other’s wallets.
This is why, when I've written an app that runs on localhost, I generate a random token to authenticate access to it, then launch a web browser pointing to the localhost URL with that token. It prevents this type of attack entirely, it's sort of like XSRF prevention.
It's what git-annex does too. In fact, it does a bit more: rather than launching the browser directly to that URL, it generates an HTML file that then redirects the browser to the URL. That prevents other users in the same system from discovering the token by looking at the process arguments.
If you are utilizing json-rpc anywhere in your stack, you should be authenticating every request via your transport(s), or the payload itself with JWT (or the like). To not do this, is to trust the world.
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).
See the details in my comment. The same way you would require authentication and/or signing on any request, on any modern platform. Not doing this is poor form.
I don't understand why DNS rebinding isn't being fixed by browser vendors. If I make an application that listens only on localhost I shouldn't have to take special steps to ensure random 3rd party remote hosts don't have access to it. The browser's DNS client could see if any recently accessed public IP now resolves to a private IP range and force a fresh CORS check.
> I regularly encounter users who don’t accept that websites can access services on localhost or their intranet. These users understand that services bound to localhost are only accessible to software running on the local machine, and that their browser is running on the local machine – but somehow believe that accessing a website “transfers” execution somewhere else. It doesn’t work like that, but this is a common source of confusion.
If you run your own resolver those can be trivially filtered out.
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
Filtering out 127.0.0.1, which is likely what these rebinding attacks utilizes, may cause problems if you run spam filters or ad blockers that use these addresses in their replies. Just something to be aware of, especially of your resolver services other clients than your personal localhost.
Adblockers shouldn't be affected since those usually are operated locally, either as part of the resolver itself or downstream by a user which can always overrule the DNS results.
And for dns blacklists you can exempt their domains from these rules.
Readit News
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
That's why a lot of the more technical people really dislike ethereum. It's not one or two problems. The entire system all the way through want made with the mentality of compromising stability in favor of getting features sooner.
* This is a "browser bypass of SOP" issue. All your "unauthenticated" local services should be vulnerable.
* A good part of Geth's usage is for servers that do not browse the internet.
* You usually do not handle accounts inside of a geth node, instead you open the node's API via RPC and have another tool that sends already-signed transactions to it. That means that this attack would probably not yield much if not allow someone to use the geth node as a public node to query public information.
* If you do decide to handle accounts in there, you would probably (1) not open the node with RPC and (2) have the accounts be encrypted. See Ethereum's documentation[1] :
> It supports interactive mode, when you are prompted for password as well as non-interactive mode where passwords are supplied via a given password file. Non-interactive mode is only meant for scripted use on test networks or known safe environments.
[1]: https://github.com/ethereum/go-ethereum/wiki/Managing-your-a...
How could anyone not consider this a vulnerability when it has an actual CVE assigned to it?
The discussion in the github issue also shows they took it pretty seriously: https://github.com/transmission/transmission/pull/468
And Ethereum is actually terrible.
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.
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?
The vulnerability is allowing the service to run without authentication.
Rather, it's a problem of DNS resolvers and browsers.
https://github.com/paritytech/parity
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).
> I regularly encounter users who don’t accept that websites can access services on localhost or their intranet. These users understand that services bound to localhost are only accessible to software running on the local machine, and that their browser is running on the local machine – but somehow believe that accessing a website “transfers” execution somewhere else. It doesn’t work like that, but this is a common source of confusion.
For example in unbound there's
And for dns blacklists you can exempt their domains from these rules.