Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chasing the DAO Attacker’s Wake – A second exploit

pdaian.com

Post reply on HN
Print view View original

81–90 of 180 posts

Re: Chasing the DAO Attacker’s Wake – A second exploit

#81

Post by freedaemon »

heliumcraft wrote: post #18

"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)." No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.

So it impacts the DAO and potentially impacts other deployed contracts (we don't know yet).

It's an issue with Solidity because it doesn't even do static analysis to give the programmar a warning.

It's not that programmers actively avoid doing this or are explicitly warned to not do it. When real money is at stake the language design needs to be a lot more careful.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#82

Post by 099812891 »

drcode wrote: post #69
heliumcraft wrote: post #18

"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)." No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.

Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.

Sure, ephemerum works in the same manner as Windows 98, Adobe Flash and sendmail.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#83

Post by goldenkey »

mbrock wrote: post #24
goldenkey wrote: post #19

Earlier quoted context omitted.

I guess you own some Ethereum and have no shame.

I'd love if we could keep HN free of these boring accusations of shilling. It makes the Reddit cryptocurrency forums really tedious to follow.

I guess the shills are out in full force this morning. Unfortunately when 40 million is on the line, people tend to greenfield and ruin the nuetral bias of social websites.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#84

Post by DennisP »

JulianMorrison wrote: post #26

Isn't this just a normal data race with stateful actors? Something modified the data while A is calling B (doesn't have to be B, could be any X) in between a call and its response. The answer to this is that mutation needs to be kept under control. Immutable data structures in mutable buckets. Locking around the data that mustn't change. Deep copy all state before calling out. And so forth. This is basically an under…

It's not quite a data race, since there's nothing parallel at all. Transactions are put in a particular order and run one at a time. So it actually does have to be B that does the modification.

One easy solution is to have just one external call per method, and always put it at the end of the method. Another is to use a single mutex for all public functions of the contract, so any callbacks fail.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#87

Post by aakilfernandes »

homogeneous wrote: post #79

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world. Even something as trivial as betting on sports requires defe…

In the scenario you gave, the trusted oracle never needs access to the funds. This is important for legal/regulatory reasons. This would not be possible without smart contracts.

Yes, its not 100% trustless, but its far more trustless than the alternative.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#88

Post by heliumcraft »

stcredzero wrote: post #71
heliumcraft wrote: post #60

Earlier quoted context omitted.

It's a code mistake by who did the DAO code. (DAO != Ethereum) It's more the equivalent of using eval in your nodejs code to evaluate some parameter received from a user. It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.

It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked. But if you're setting up a situation where server after server is constantly compromised because of hard to discern reasons, then yes, that is a bad idea. Having an internet is something as obviously good as electrical wiring and highway bridges. Having a badly implemented internet is as obviously bad as fault…

Essentially this is the equivalent of a dev mistakely using an eval in the wrong place in a nodejs code. But all these articles are making it sound like the Ethereum team created the DAO and this issues affect Ethrereum as whole, which just isn't true.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#89

Post by axlee »

DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

If this code style is an absolute requirement for the code not to be exploited, it should be probably be built-in in the language specification itself.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#90

Post by gomox »

homogeneous wrote: post #79

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world. Even something as trivial as betting on sports requires defe…

Some simple use cases:

- a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.

- payment schedules or any kind of transaction that does not function exactly like a one time, full size payment (payments, debt, etc).

- more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked

In all of the above the inputs are contained in the blockchain and therefore have no need for trusted oracles.

Post reply on HN