6 ms·

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 b

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...
  - mannykannot 9y ago
    I don't know if the abstractions of Safe Haskell, or something like it, will be sufficient. The link you gave seems to imply that the guarantee of trustworthiness is restricted to something less than every aspect of the code's semantics. One problem, as I see it, is that, from a computing point of view, a fraudulent contract may be indistinguishable from a valid one. You see this principle in the claim sometimes made that the DAO hack was not theft because a contract means exactly what its code does, nothing more and nothing less (that's not a view I hold, of course, or I would not be worrying that theft is possible.)
- tom_mellior 9y ago
  It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. C, Rust, and Haskell are all Turing-complete, and while of course it's possible to write buggy code in all of them, certain classes of bugs that are possible in C are not possible in Haskell. > there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written True, but there is the possibility of trivial changes that would prohibit some exceptionally catastrophic bugs. The language features that allowed last weeks multisig walled bug (delegation to an unknown function, public initialization code, the possibility of calling initialization code after initialization) need not be like that. A much better language could still be Turing complete but exclude such things (forcing you to write explicit code that shoots you in the foot, if you so wish).
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.

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...
- mannykannot 9y ago
  I don't know if the abstractions of Safe Haskell, or something like it, will be sufficient. The link you gave seems to imply that the guarantee of trustworthiness is restricted to something less than every aspect of the code's semantics. One problem, as I see it, is that, from a computing point of view, a fraudulent contract may be indistinguishable from a valid one. You see this principle in the claim sometimes made that the DAO hack was not theft because a contract means exactly what its code does, nothing more and nothing less (that's not a view I hold, of course, or I would not be worrying that theft is possible.)
tom_mellior 9y ago
It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. C, Rust, and Haskell are all Turing-complete, and while of course it's possible to write buggy code in all of them, certain classes of bugs that are possible in C are not possible in Haskell. > there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written True, but there is the possibility of trivial changes that would prohibit some exceptionally catastrophic bugs. The language features that allowed last weeks multisig walled bug (delegation to an unknown function, public initialization code, the possibility of calling initialization code after initialization) need not be like that. A much better language could still be Turing complete but exclude such things (forcing you to write explicit code that shoots you in the foot, if you so wish).

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.