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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017