www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] - A hacker stole $31M of =?UTF-8?B?RXRoZXLigIrigJTigIpob3c=?= it

reply Nick B <nick.barbalich gmail.com> writes:
See - 
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

A long read. Someone has stolen $31M of Ether.

Interesting quote near the end of the article:

In blockchain, code is intrinsically unrevertible. Once you 
deploy a bad smart contract, anyone is free to attack it as long 
and hard as they can, and there’s no way to take it back if they 
get to it first. Unless you build intelligent security mechanisms 
into your contracts, if there’s a bug or successful attack, 
there’s no way to shut off your servers and fix the mistake. 
Being on Ethereum by definition means everyone owns your server.
A common saying in cybersecurity is “attack is always easier than 
defense.” Blockchain sharply multiplies this imbalance. It’s far 
easier to attack because you have access to the code of every 
contract, know how much money is in it, and can take as long as 
you want to try to attack it. And once your attack is successful, 
you can potentially steal all of the money in the contract.
Imagine that you were deploying software for vending machines. 
But instead of a bug allowing you to simply steal candy from one 
machine, the bug allowed you to simultaneously steal candy from 
every machine in the world that employed this software. Yeah, 
that’s how blockchain works.

But can a digital wallets/crypto currency ever be secure  ?

Nick
Aug 03
next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
 See - 
 https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

 [...]
I don't think the problem was with the blockchain here. It is usually a bad idea to have turing-complete scripts over blockchains. From what I've seen the bug was that there was issued a library call based on a user-provided string. That could have never happened if they would have used D with safe
Aug 04
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/4/2017 1:33 AM, RazvanN wrote:
 That could have never happened if they would have used D with  safe
That's mostly true, but not absolutely true. 1. There can be bugs in D's safe checking and inference. 2. Function interfaces (such as in C interface files) are labeled safe or not, and the D compiler has no way to check. Hence, functions can (and have been) mislabeled. On the other hand, safe does greatly reduce the attack surface. And as I've prognosticated before, the utter lack of machine checkable memory safety in C will herald the end of its use in anything connected to the internet.
Aug 04
parent reply Maksim Fomin <mxfm protonmail.com> writes:
On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote:
 On 8/4/2017 1:33 AM, RazvanN wrote:
 That could have never happened if they would have used D with 
  safe
That's mostly true, but not absolutely true. 1. There can be bugs in D's safe checking and inference. 2. Function interfaces (such as in C interface files) are labeled safe or not, and the D compiler has no way to check. Hence, functions can (and have been) mislabeled. On the other hand, safe does greatly reduce the attack surface. And as I've prognosticated before, the utter lack of machine checkable memory safety in C will herald the end of its use in anything connected to the internet.
So, you agree that safe cannot solve the problem because of C function interfaces and 'lack of machine checkable memory safety in C'. In this case, why does safe relies on static analysis in CT and type inference when memory safety is determined by the 'C memory sate' at RT? Either safe is wrongly presented (it is not memory safety tool, but something else) or (if the intention was to provide memory safety tool) it is a flawed feature. Of course, memory safety is impossible in C. In my opinion, D's safe is wrongly marketed as a fully safety tool (look at a user above). This is dangerous, because leads to unfounded assumptions and later disappointment. By the way, I see that DIP 100 followed the same way - impose static type restrictions in CT to prevent memory errors. I believe, due to growing language complexity any combination of resctrictions can have loopholes. Back in 2013 I was collecting type system holes and posted them in Bugzilla after your request. It appears, that scope has its own loopholes too [1]. [1] https://issues.dlang.org/show_bug.cgi?id=17718
Aug 04
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/4/2017 2:26 AM, Maksim Fomin wrote:
 So, you agree that  safe cannot solve the problem because of C function 
 interfaces and 'lack of machine checkable memory safety in C'. In this case,
why 
 does  safe relies on static analysis in CT and type inference when memory
safety 
 is determined by the 'C memory sate' at RT? Either  safe is wrongly presented 
 (it is not memory safety tool, but something else) or (if the intention was to 
 provide memory safety tool) it is a flawed feature.
Every memory safe language that talks to C code (Rust, Java, etc.) has this issue. Once you step outside the language, guarantees cannot be made. It's not reasonable to assume otherwise.
 It appears, that scope has its own loopholes too [1].
 [1] https://issues.dlang.org/show_bug.cgi?id=17718
All languages have bugs in their implementations. What do you suggest we do about that?
Aug 04
prev sibling parent Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Friday, 4 August 2017 at 08:33:42 UTC, RazvanN wrote:
 On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
 See - 
 https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

 [...]
I don't think the problem was with the blockchain here. It is usually a bad idea to have turing-complete scripts over blockchains. From what I've seen the bug was that there was issued a library call based on a user-provided string. That could have never happened if they would have used D with safe
D's OpDispatch is very similar to what caused this bug ;) struct Library { void doSomethingUseful(){} void doSomethingNice(){} void resetSecurity(){} } struct BuggyContract { private void customizedBehaviour(){} void opDispatch(string f)() { if(f == "doSomethingUseful") { customizedBehaviour(); } else { mixin("Library.init." ~ f ~ "();"; } } }
Aug 04
prev sibling next sibling parent Johnson Jones <JJ Dynomite.com> writes:
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
 See - 
 https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

 But can a digital wallets/crypto currency ever be secure  ?
Nope... as long as humans continue to build house of cards on quicksand this sort of stuff will always happen. You do realize it's all fake nonsense? If the only sort of currency that existed was what you could immediately do with your own body, then it would be impossible to ever steal anything(except for slavery, which is essentially still fake). Basically this is how the story goes: Someone comes up with some scheme to gather resources from others. The scheme is complex and designed in such a way that only those that have created the scheme or invested enough time to understand the scheme benefit from all those that don't but were to stupid not to buy in to the scheme. Eventually those at the top win. It's called a pyramid scheme and it exists in all forms of currency, employment, governments, even in most relationships, etc. Only when all participants equally share complete responsibility can the scheme be fair... but that never happens, too much to gain when it becomes unbalanced... and the more unbalanced it becomes the more those that unbalance it get. I wouldn't doubt that most of these people who create these currencies are the ones that ultimately are behind these thefts. After all, they are the ones that know most about it and why else would they spend their time developing it? For the benefit of human kind? Yeah right! What a joke!
Aug 04
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
 See - 
 https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

 A long read. Someone has stolen $31M of Ether.
To give an idea of how bad it is: https://news.ycombinator.com/item?id=14691212 Anyone writing smart contracts on ETH right now is crazy.
Aug 04