> 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 general public shouldn't be excited about blockchain. It should be hidden by abstraction to them, like multithreading and device drivers. Products intended for non-technical users that tout their blockchain technology are either really missing the mark on marketing or trying to pull the wool over consumers' eyes with buzzwords.
Tech folk should be excited about blockchain but the hysteria over exchanges right now is off-putting once you understand how deeply rigged the markets are. My next venture will be blockchain-based but I have a few years before I'm free to pursue that. I'd rather see the fundamentals of the tech improved in the meantime rather than have it prematurely hyped and have the bubble pop as I seek to raise funding...
I imagine there are many others who are in the position of wanting to build apps based on blockchain tech but who are not yet able. For us, slow and steady wins the race.
It sounds like you're trying to tell the market what it should and should not buy. That's not how it works. The market tells you what it has chosen, then you can choose your reaction to it. Your reaction seems to be "disapproval"? Well that's mildly interesting I guess.
Saying "they're missing the mark on marketing" about the second-largest crypto by market-cap, and surely top-5 in terms of ongoing development is at the very least a bit ironic. They exactly did NOT miss the mark on marketing. There are other technically superior products that don't get nearly as much funding, public attention, development resources etc.
‘The market’ bought investment funds from Bernie Maddoff, and more recently Martin Shkreli. In February it thought the Dow was worth 24,515 one day and 1,600 points less the next. Sometimes the market is wrong, whatever free market fundies will tell you.
From an investor's perspective, sure, the market can be "wrong"; and avoiding its incorrect beliefs and hype-trains is how you make gains while avoiding losses.
As an entrepreneur, though, the market makes the final decision on whether you make money, whether it's "right" or "wrong." If you're "right" when the market is "wrong" as an entrepreneur, you lose—you're "ahead of your time" or some other pleasantry meaning "you weren't giving the market what it wanted."
If you want to sell something to the market, then if the market is irrationally exuberant, you have to be irrationally exuberant too.
You don’t have to be irrationally exuberant to succeed in the market, even if it’s irrationally exuberant. Is every single company on earth leaping and dancing to the latest fad of the minute in order to succeed? Is the secret of Warren Buffets’s success piling in on on all the latest trends? No, yet somehow our economy seems to bubble along ok. So I categorically reject the idea that this is the only way success is gauged, that’s self evidently not true.
Secondly, if the market is wrong and you dance to that tune, eventually when reality catches up the market will realise it’s mistake. Trust me, the market can sell out of your company faster than you can pivot your entire business model.
But sure, it is possible to make money following trends. But it’s not the only way. It’s not an immutable law of capitalism, and there’s plenty of money to be made providing actual, sustainable value.
>You don’t have to be irrationally exuberant to succeed in the market, even if it’s irrationally exuberant.
Yes, but it is risky. If you don't follow trends/buzzwords you have two threats:
1) You bet that many people (the market) are wrong and you are right. Possible, but unlikely.
2) You bet that after these many people (the market) come to senses and realize that they were wrong (remember: nobody likes to admit that they were wrong), they acknowledge that you are right and buy your product. As the funny saying goes: "the market can stay irrational longer than you can stay solvent".
Absolutely. In no way was my comment saying that the market sentiment is somehow an accurate measure of the underlying quality or even utility of such a product. If anything, I think there are much better projects out there already.
But in a way, being a market leader gives a lot of adoption and a big ecosystem of tools produced by other developers - which in this space means a lot, because a blockchain's usability increases with adoption, even somewhat exponentially.
I think you miss my point and that you've never tried to sell a technology solution to non-technical consumers. The world is bigger than crypto speculators.
This happened for waltonchain. They got caught red handed faking a community giveaway, and that was a big enough story to bring them into the spotlight and push them into the top 30 cryptocurrencies by market cap for a bit.
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?
People don't like to hear this, but blockchain tech isn't ready for a general app platform. Bitcoin could easily be extended to have an EVM if it was a good idea, but there are lots of unsolved problems, gotchas, and overheads that make it a poor choice. I don't think that's the perpetual state of things, but I do think that every 'dapp' platform out there today is bad foundation, and largely that's because it's too early to be making general platforms.
The approach that a couple of currencies have taken (including the one I lead) is to make a separate blockchain entirely dedicated to their app. And I think that's a far better choice than anything out there, though it comes with the glaring downside of needing to build and run your own blockchain, which is a very difficult thing to do.
Most of the apps we are seeing today don't make any sense anyway. Very much smacks of the dotcom bubble, where people who suspected that the Internet would change the world were absolutely correct, but then the companies and ideas they put their money behind were missing the mark by miles.
We've got the same issue today. Most successful ICOs are going to fail very hard, due to known impossibilities, known poor uses of the technology, etc. It's just a general fever that has a lot of new entrants in the space innovating in the wrong direction.
It will get better. Dapp platforms will appear that make sense, have good foundations, and are easy to setup and use. But it's not around the corner, it's probably 3-5 years away.
> Most of the apps we are seeing today don't make any sense anyway. Very much smacks of the dotcom bubble, where people who suspected that the Internet would change the world were absolutely correct, but then the companies and ideas they put their money behind were missing the mark by miles.
This is the crux of the problem. The cryptocurrencies with the highest valuations right now are ones with serious technical and social flaws--people are investing in cryptocurrencies based on hype rather than merit.
Ethereum is the most egregious example: the idea that a JavaScript-like language is what you'd want to write your security-intensive code in is mind-boggling-ly stupid, and after the community showed themselves to be willing to perform a 51% attack on their own blockchain to fix a problem with the DAO, it's not even decentralized any more. So technically you have all the downsides of writing secure software in JavaScript, and socially you have all the problems of centralization AND all the problems of decentralization. The security flaw this thread is about would be a critical vulnerability to any competent security developer, but it's really minor compared to the more fundamental flaws.
But even in competently-developed cryptocurrencies, the problems are still there because people don't understand or value decentralization, which is literally the entire reason Blockchain is worthwhile. The number of people who buy cryptocurrencies and then leave their coins sitting on an exchange is incredible. You're literally donating money to the world's biggest bug bounties when you do that.
In my opinion, decentralization is not the point of crypto-tech. Maybe it's some minor feature, but not the selling proposition. The major feature is the formalisation of the concept of consensus. Forks are a manifestation of this feature. "a 51% attack on their own blockchain" is a major feature of crypto-tech. In the last century we would call this a revolution. In this century issues like this can be resolved enterily in software. It's an opt-in economy and in some years an opt-in society.
The only reason you think the cash in your portemonai is worth something is that everybody else things the same. As soon as everybody stops believing it, the paper in your wallet can still be used to make fire. Same goes for authorities. Judges, policemen, presidents are what they are because everybody believes it. We have already an informal consensus of who is a policeman and who is not. Most of the time it resolves to whether somebody wears the uniform. Crypto tech promises to make this verifiably. No need for uniforms.
> The major feature is the formalisation of the concept of consensus. Forks are a manifestation of this feature. "a 51% attack on their own blockchain" is a major feature of crypto-tech. In the last century we would call this a revolution. In this century issues like this can be resolved enterily in software. It's an opt-in economy and in some years an opt-in society.
Huh? No. Distributed consensus was formalized in 1978 by Leslie Lamport and the first version of Paxos was introduced in 1989. If you're okay with centralization, Paxos or it's successor, Raft, are much faster and more scalable algorithms than blockchain, and have a wide variety of mature implementations.
> People don't like to hear this, but blockchain tech isn't ready for a general app platform.
This cannot be stressed enough. But, I disagree that building your own blockchain is the answer in comparison to using EVM. The amount of blockchains and services people might end up needing will be huge. So, it seems the correct usage for blockchain is still far out.
I agree with this overall, but have serious reservations here:
Bitcoin could easily be extended to have an EVM
are you talking about Script, or some other approach I don’t know about? I think it’s pretty optimistic to put the word “easily” anywhere near a proposed use of Script.
I don't know about "easily", but that's pretty much exactly what Qtum did. It's a UTXO blockchain with EVM and other smart contracts on top. It required about 6 solid months to figure out how to make it work and the output of that is something called "The Account Abstraction Layer" to basically decouple smart contracts from the underlying blockchain protocol
NEO is still very raw, and it takes a lot of work to get involved, however it’s a tight nit developer community and some serious opportunities to get involved and shape the project. Source: I am active in the developer community and have a company building on NEO
I’ve been interested in NEO but not sure where to begin. Do you have any links you could recommend? Also tell a bit more about your company and what you are building if you’d like.
Thanks. I checked out your site and it mentions open source and commitment to the community but I can’t find the repo for your iOS wallet on https://github.com/O3Labs
Waves platform, NEM, NEO, many others.
Replacing (or at least partially re-capturing a part of) Ethereum's success is one of the next big things that many projects are trying to do. It became clear that some form of smart contracts are considered very valuable by the market, at least ICOs - and it's clear that a platform that will win in this regard will become Huuge. There are also clear disadvantages that Ethereum has, so this is an obvious vacuum that many projects are trying to fill.
A lot of the commenters here don't understand the cryptocurrency market and are vastly overstating Ethereum's flaws.
The truth is that the EVM is perfectly secure and the problems with Solidity are due to the fact that any new smart contract development environment was bound to have problems at the initial stages.
Solidity is being rapidly improved and there are several other programming languages under development for the EVM as well.
As for market significance, Ethereum is the only smart contract platform that's relevant.
There are now over a million MetaMask installations that can interact with any Ethereum Dapp, and millions of MEW wallets that can hold ERC20 tokens.
Ethereum-based tokens saw their share of the total token market cap grow from 73% to 92% from July 2017 to January 2018. The platform has 30X more developers working on it than the next most active one.
That means that almost all of the decentralized exchanges and other value-adding applications are compatible with the ERC20 standard, creating a positive feedback loop of encouraging new projects to build on Ethereum.
Ethereum is more likely than not going to be the platform for smart contract development.
Qtum sounds like the thing you could be looking for. To TL;DR; it, Qtum is a smart contract platform on an independent blockchain that supports PoS (not DPoS, true PoS) and designed to support multiple smart contract VMs. Right now it only supports the EVM and thus can only run Solidity smart contracts, but later this year we'll release a new VM based on the x86 architecture so that it will be possible to use mainstream languages like C++, Rust, Go, etc...
Anyway, ending the whole description bit, we built it because of similar thoughts as you. Tired of seeing the only suitable smart contract platform (Ethereum) be treated like some philosophical research project, rather than a platform that businesses and people stake hundreds of millions of dollars on. Everything we design is intended to be practical to not just use, but also implement. We pride ourselves in never missing any deadlines we set for ourselves, and in never having some pipe dream project that won't be ready to use for 5 years.
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.
It is certainly a vulnerability. It just isn't a vulnerability in the torrent client, but rather with browsers. Note that this PR is to mitigate the vulnerability, not to fix it.
I don't understand how an unauthenticated RPC service is not a vulnerability just because it only listens on localhost. I'm not aware of any sensible security model which assumes that all code running on the local computer with network access is trustworthy. Even the old, standard UNIX security model only assumes that code running under your user is trustworthy.
I think that it's a vulnerability in browser. It was surprise for me, that it's possible to issue POST requests to some completely unrelated website just because dns changed its IP. 127.0.0.1 is one example, but I'm sure that there are billions websites which process POST requests for important actions and their webserver doesn't check "Server:" header. This attack just circumvents origin policy, it's definitely a browser bug.
Well, it's all relative to the threat model. It makes some sense on a single-user machine where you don't run any untrusted code, as the same user or not.
On a single-user machine, an attack scenario where authenticating localhost would actually do some good would be some other account existing that's easier to break into than the account of the user actually doing stuff. But if no other login exists?
It should be noted that a desktop is not a single user machine, even though there may only be one human user operating the machine. A single user machine is a machine running in runlevel 1 -- in other words every process on the machine is running as one user and you cannot switch users.
Modern desktops do not run at runlevel 1. All sorts of services and daemons run under different users, so having an unauthenticated service listening on localhost is less secure even on a desktop machine. If you have network services running on a desktop machine (common) then a simple RCE in an unprivileged user (with respect to the human user) can result in wallet compromise. If the API was authenticated that would not be possible.
Unix DAC protects users from one another, so any service which exposes personal information outside of the currently running user has objectively inferior security to a security model invented in the 1960s.
I can see where you might set things up like that on a single-user machine after careful consideration of everything that's running on it. But making that the default seems like madness.
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.
The victim needs to be running a local geth node(with his wallet unlocked for hacker to actually steal funds) which will give the attacker the wallet addresses atleast.
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.
These ‘protections’ do not provide a ‘trusted context’ and cannot defend you from another user on the same computer.
Now your next mistake will be saying ‘but typically there’s only one user’ which is irrelevant because the system runs services as different users for isolation purposes and this vulnerability ignores this isolation.
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.
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.
This is just one of many vulnerabilities in Geth and other Ethereum clients due to unauthenticated JSON-RPC on localhost. You might recall this even hit Redis years ago.
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 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.
>Since the DNS cache has expired, the browser resolves the DNS again. This time, my server responds with an IP of 127.0.0.1.
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.
Can we all come together and encourage browser developers to fix their shit instead of blaming every service that makes reasonable assumptions about localhost.
I do think that Ethereum ought to authenticate it's JSON-RPC service, but not because of DNS rebinding.
I don't think it has anything to do with DNS rebinding, but it seems like it would have a lot to do with having unauthenticated RPC services bound to localhost.
Sandboxing means preventing the code from accessing local resources. If that requires whitelisting acces to specific IPs then so be it (although in this case there are other possible solutions).
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