11 ms·

I don't really follow Ethereum, but from headlines on Hacker News I've learned that 1. Ethereum is difficult to work with 2. Its difficulty does not provide s

by huntie 9y ago

I don't really follow Ethereum, but from headlines on Hacker News I've learned that 1. Ethereum is difficult to work with 2. Its difficulty does not provide security This doesn't exactly inspire confidence in it. Some comments on this article imply that this was just a scam, so maybe Ethereum is secure. I think that a lot of people learn about things they don't care about via headlines, which may be damaging for Ethereum in its infancy.

sharemywin 9y ago
That would be true if it was steady-state, but there are a lot of people working things in the ecosystem that make it stronger.
- jbmorgado 9y ago
  I guess you can say that Ethereum is also in the "strong and stable" category.
  - sharemywin 9y ago
    I wouldn't get ahead of ourselves.
Nekorosu 9y ago
Development on top of ethereum platform is in it's infancy. SQL injection attacks were as frequent when web development was young. I haven't checked it myself but I guess the current API is quite low level and doesn't include higher level abstractions to prevent this kind of attacks. Also there are no established development practices regarding security.
- hn_throwaway_99 9y ago
  But the difference is in the impact of security flaws. It's bad enough if someone steals a bunch of credit card numbers through SQL injection, but at least individuals are indemnified. With Ethereum, poof, it's gone forever.
- mannykannot 9y ago
  > I guess the current API is quite low level and doesn't include higher level abstractions to prevent this kind of attacks. A fundamental principle of Ethereum is that its smart contracts have Turing-complete computing power. Therefore, there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written (even if the abstractions are limited in their power, an attacker can make use of the full power of the underlying system.) Writing provably-secure smart contracts is as difficult as writing provably-secure software for any other Turing-complete platform: i.e. only a small percentage of developers can do it. Furthermore, the software that comprises the platform itself has not been stringently verified. Of course, we are using lots of software in banking and finance that is not formally verified, but there are significant differences: it runs in secured environments with controlled and very limited external access, and there are out-of-band methods for correcting mistakes. In contrast, blockchain currencies are actually promoted as being immune to this sort of interference on account of transactions being irrevokable (and no, the hard fork that rescued the DAO participants is not a counter-example, as that will not be feasible in future.) I cannot say these problems will not be resolved in the future, but why would anyone put any significant value at risk until they are?
  - Nekorosu 9y ago
    Thanks! That's really interesting and makes sense. I should definitely do some research on the topics you've mentioned. Your closing questions has a point I agree on.
  - runeks 9y ago
    > Therefore, there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written (even if the abstractions are limited in their power, an attacker can make use of the full power of the underlying system.) High level abstractions and Turing completeness are not in opposition. Haskell, for example, offers high level abstractions in the form of a functional language with abstract data types, strong typing and purity (unless you specify something else explicitly, functions only have access to their arguments). I think Safe Haskell would be a good Turing-complete, general purpose contract language. Untrusted code can be compiled to machine code and executed safely, by using a restricted IO monad that only allows specific input/output operations[1], so the contract logic can be executed safely without a sandbox. [1] https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_guide/safe-haskell.html https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_gui...
- wslh 9y ago
  It is much different from SQL injection. There were ways to prevent SQL injection in the same programming language and less money at stake on every corner. Solidity and the EVM are an invitation to be hacked.
  - Nekorosu 9y ago
    I've never said they're the same. Probably I wasn't clear enough but it was analogy not a technical comparison. Your clarifications make sense though.
- swiley 9y ago
  The argument I've heard is that it's abstracted but the abstraction is bad.
- naasking 9y ago
  > Development on top of ethereum platform is in it's infancy. Oh please, a lot of people keep saying this, but the reality is that Ethereum and Solidity devs simply didn't do enough research. There's a long history of smart contract platforms that are both safer and more robust, and the problems inherent to the choices Solidity made were obvious right when it was first introduced: http://lambda-the-ultimate.org/node/5003 http://lambda-the-ultimate.org/node/5003
  - Nekorosu 9y ago
    Always nice to read a discussion on lambda the ultimate. :)
    - naasking 9y ago
      Discussion is ongoing! Some of these recurring security issues just seriously annoy me, so I'm posting more references and discussion to that thread to document all the flaws of EVM and its languages, and the solutions to them that have existed for literally decades at this point.
  - meesterdude 9y ago
    > Oh please, a lot of people keep saying this, but the reality is that Ethereum and Solidity devs simply didn't do enough research. FUD. What are you talking about? Solidity is not so unsafe, nor is it correct to imply that Vitalik "didn't do his research". MAYBE he did his research and came to a different conclusion? Maybe hhis priorities were different? Regardless, he's exceptionally bright and by no measure just a hasty dev trying to make a quick buck. And your link does not point to any inherent flaws in Solidity, just opinions on language fit. Ethereum development IS in it's infancy. It WILL improve over time - like it or not.
    - bllguo 9y ago
      This is almost cult-like. The cult of Vitalik. What we're talking about are a slew of successful attacks in the ETH ecosystem. What we're talking about are what appear to be questionable decisions in Solidity. What do you think of this thread earlier? https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 It is clearly unsafe, judging from these attacks. It is clearly not designed with security in mind, which should have been a top priority. "Maybe his priorities were different" is even more damning than if people did prioritize security and failed.
- sp332 9y ago
  Injection attacks including SQL injection are still at the top of the OWASP Top 10 vulnerabilities. They're still very common and very damaging. Don't expect those kinds of vulnerabilities to ever disappear.
- kalleboo 9y ago
  SQL injection attacks are STILL frequent. Heck, buffer overflow bugs are decades old but still happen all the time. Software security has practically not gotten any better over the years. Best practices are now known but rarely followed. Even when you follow best practices, there are vulnerabilities. Software security is an illusion.
legohead 9y ago
This "hack" doesn't have anything to do with Ethereum. Someone "hacked" a new coin ICO and then sold them for Ethereum.

by huntie 9y ago

sharemywin 9y ago

That would be true if it was steady-state, but there are a lot of people working things in the ecosystem that make it stronger.

jbmorgado 9y ago
I guess you can say that Ethereum is also in the "strong and stable" category.
- sharemywin 9y ago
  I wouldn't get ahead of ourselves.

Nekorosu 9y ago

Development on top of ethereum platform is in it's infancy. SQL injection attacks were as frequent when web development was young. I haven't checked it myself but I guess the current API is quite low level and doesn't include higher level abstractions to prevent this kind of attacks. Also there are no established development practices regarding security.

hn_throwaway_99 9y ago
But the difference is in the impact of security flaws. It's bad enough if someone steals a bunch of credit card numbers through SQL injection, but at least individuals are indemnified. With Ethereum, poof, it's gone forever.
mannykannot 9y ago
> I guess the current API is quite low level and doesn't include higher level abstractions to prevent this kind of attacks. A fundamental principle of Ethereum is that its smart contracts have Turing-complete computing power. Therefore, there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written (even if the abstractions are limited in their power, an attacker can make use of the full power of the underlying system.) Writing provably-secure smart contracts is as difficult as writing provably-secure software for any other Turing-complete platform: i.e. only a small percentage of developers can do it. Furthermore, the software that comprises the platform itself has not been stringently verified. Of course, we are using lots of software in banking and finance that is not formally verified, but there are significant differences: it runs in secured environments with controlled and very limited external access, and there are out-of-band methods for correcting mistakes. In contrast, blockchain currencies are actually promoted as being immune to this sort of interference on account of transactions being irrevokable (and no, the hard fork that rescued the DAO participants is not a counter-example, as that will not be feasible in future.) I cannot say these problems will not be resolved in the future, but why would anyone put any significant value at risk until they are?
- Nekorosu 9y ago
  Thanks! That's really interesting and makes sense. I should definitely do some research on the topics you've mentioned. Your closing questions has a point I agree on.
- runeks 9y ago
  > Therefore, there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written (even if the abstractions are limited in their power, an attacker can make use of the full power of the underlying system.) High level abstractions and Turing completeness are not in opposition. Haskell, for example, offers high level abstractions in the form of a functional language with abstract data types, strong typing and purity (unless you specify something else explicitly, functions only have access to their arguments). I think Safe Haskell would be a good Turing-complete, general purpose contract language. Untrusted code can be compiled to machine code and executed safely, by using a restricted IO monad that only allows specific input/output operations[1], so the contract logic can be executed safely without a sandbox. [1] https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_guide/safe-haskell.html https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_gui...
wslh 9y ago
It is much different from SQL injection. There were ways to prevent SQL injection in the same programming language and less money at stake on every corner. Solidity and the EVM are an invitation to be hacked.
- Nekorosu 9y ago
  I've never said they're the same. Probably I wasn't clear enough but it was analogy not a technical comparison. Your clarifications make sense though.
swiley 9y ago
The argument I've heard is that it's abstracted but the abstraction is bad.
naasking 9y ago
> Development on top of ethereum platform is in it's infancy. Oh please, a lot of people keep saying this, but the reality is that Ethereum and Solidity devs simply didn't do enough research. There's a long history of smart contract platforms that are both safer and more robust, and the problems inherent to the choices Solidity made were obvious right when it was first introduced: http://lambda-the-ultimate.org/node/5003 http://lambda-the-ultimate.org/node/5003
- Nekorosu 9y ago
  Always nice to read a discussion on lambda the ultimate. :)
  - naasking 9y ago
    Discussion is ongoing! Some of these recurring security issues just seriously annoy me, so I'm posting more references and discussion to that thread to document all the flaws of EVM and its languages, and the solutions to them that have existed for literally decades at this point.
- meesterdude 9y ago
  > Oh please, a lot of people keep saying this, but the reality is that Ethereum and Solidity devs simply didn't do enough research. FUD. What are you talking about? Solidity is not so unsafe, nor is it correct to imply that Vitalik "didn't do his research". MAYBE he did his research and came to a different conclusion? Maybe hhis priorities were different? Regardless, he's exceptionally bright and by no measure just a hasty dev trying to make a quick buck. And your link does not point to any inherent flaws in Solidity, just opinions on language fit. Ethereum development IS in it's infancy. It WILL improve over time - like it or not.
  - bllguo 9y ago
    This is almost cult-like. The cult of Vitalik. What we're talking about are a slew of successful attacks in the ETH ecosystem. What we're talking about are what appear to be questionable decisions in Solidity. What do you think of this thread earlier? https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 It is clearly unsafe, judging from these attacks. It is clearly not designed with security in mind, which should have been a top priority. "Maybe his priorities were different" is even more damning than if people did prioritize security and failed.
sp332 9y ago
Injection attacks including SQL injection are still at the top of the OWASP Top 10 vulnerabilities. They're still very common and very damaging. Don't expect those kinds of vulnerabilities to ever disappear.
kalleboo 9y ago
SQL injection attacks are STILL frequent. Heck, buffer overflow bugs are decades old but still happen all the time. Software security has practically not gotten any better over the years. Best practices are now known but rarely followed. Even when you follow best practices, there are vulnerabilities. Software security is an illusion.

legohead 9y ago

This "hack" doesn't have anything to do with Ethereum. Someone "hacked" a new coin ICO and then sold them for Ethereum.