Live data from Hacker News

Critical Update on DAO Vulnerability

blog.ethereum.org

581–590 of 629 posts

Re: Critical Update on DAO Vulnerability

#581
post #488
post #347

Earlier quoted context omitted.

1. You just make an agreement with someone who would like to buy your tokens for some national currency. If you ever played an MMORPG or Diablo 2 or something, you know that "imaginary" digital items can be traded for "real" money. There are many exchanges where you can do this conveniently. 2. For one example, consider how tedious it is to open a new bank account; with cryptocurrency, you just make a new keypair. Sm…

In the country of my current residence, there are government plans running that provide additional benefits beyond simple salaries. These are food-tickets, leisure and vacation credit that are allocated on plastic cards. I loathe these. They are a way of faking actual payment. These credits and tickets are not accepted everywhere, unlike the currency of the country is. They carry second-class monetary value, and the…

National currencies must also be exchanged for other currency when you want to spend in some other currency regime. I can't spend my SEK elsewhere without exchanging, just like with BTC and ETH.

Even so, an asset can be valuable even if it's not used as daily currency. You can't buy a Coke with gold.

Re: Critical Update on DAO Vulnerability

#582
post #472

My guess at how the attackers are doing it: They are calling splitDAO: https://github.com/slockit/DAO/blob/develop/DAO.sol#L618 splitDAO calls withdrawRewardFor which ends up calling back into the users contract. https://github.com/slockit/DAO/blob/develop/DAO.sol#L686 withdrawRewardFor(msg.sender); // be nice, and get his rewards totalSupply -= balances[msg.sender]; balances[msg.sender] = 0; paidOut[msg.sender] = 0;…

This makes sense to me, but where's the actual code that calls into the attacker's contract and lets the attacker call back into splitDAO? And how on Earth is it a good idea to allow one contract to call another? There are any number of more sensible ways to communicate that don't have this problem: allow contracts to pass messages to other contracts, allow contracts to subscribe to each other's events, etc.

withdrawRewardFor ends up calling ManagedAccount#payOut which does _recipient.call.value(amount):

    function payOut(address _recipient, uint _amount) returns (bool) {
        if (msg.sender != owner || msg.value > 0 || (payOwnerOnly && _recipient != owner))
            throw;
        if (_recipient.call.value(_amount)()) {
            PayOut(_recipient, _amount);
            return true;
        } else {
            return false;
        }
    }
so the 'vulnerable' code is calling a function in another contract and it is this function that is doing the external callback. this is why security is so hard. everytime you add an external callback you need trace all of your callers to check that they are correctly re-entrant or everytime you use another function you need to trace forward to make sure it doesn't have any external callbacks.

Re: Critical Update on DAO Vulnerability

#583

This is what concerns me about contract programming. With human contract law, if there's a minor typo or loophole, participants can generally see the spirit and intent, and at worst go to a judge who will usually enforce the intent. But with software contracts, only the characters matter and there's no intent anywhere: either you get paid or you don't. ETH is advising, "Contract authors should ... be very careful abo…

>This is what concerns me about contract programming. With human contract law, if there's a minor typo or loophole, participants can generally see the spirit and intent, and at worst go to a judge who will usually enforce the intent. But with software contracts, only the characters matter and there's no intent anywhere: either you get paid or you don't.

It's much worse than that!! What you've just said applies to building an airplane or getting to Mars, too. Mother nature won't care what you meant to do.

But this is worse: mother nature might give you turbulence, but She won't carefully cycle or time the turbulence in a code injection vulnerability to try to get your avionics to lock up at some particular moment. With these kinds of systems, you have humans actively doing everything in their power to break the system, even using the most subtle possible tricks. It's not just noise: it's a malicious attacker.

It's not enough to "get it right". You have to get it right against someone with lockpicking tools, budget, time, and no legal, social, or moral checks and balances. By that standard, every vehicle NASA has ever built is completely broken, and NASA has never built a single thing that works.

It's not just about code that's correct. It's about code to held to literally supernatural standards of correctness.

It's a social problem.

Re: Critical Update on DAO Vulnerability

#584
post #255

Earlier quoted context omitted.

I see a different problem here: Ethereum and the DAO were not in a mature state to handle this amount of money. For example, there is a limited support for upgrading contracts in Ethereum and the DAO was not reviewed enough to handle hundreds of million dollars. Also, there are methods to make the software ultra secure using formal models.

Contracts can be upgraded if they're designed that way. You can have a wrapper contract that just calls out to other contracts, where the addresses of the other contracts are updateable. You can even make the callee run in the context of the caller, so all the data is held at the caller, which calls an external function that manipulates it. Doing this is a tradeoff. On the one hand it lets you fix bugs and vulnerabil…

Until such time as a College of Hortators gets invented and people start including standard provisions to defer some decisions to them. Yay, the courts have been reintroduced.

Re: Critical Update on DAO Vulnerability

#585

Earlier quoted context omitted.

In other words, this contract is too big to fail?

Perhaps, but: a) It is being bailed out by referendum, not mandate. Everyone gets a vote, if you don't want to install the patch, don't do it. b) The funds to bail it out are those stolen by the attacker. Nobody is asking people without DAO tokens to suddenly contribute their ether to restoring the DAO or take debt.

Is there really an attacker and stolen funds though?

I mean, the contract executed exactly as specified.

If the system was well designed, there would be no way to undo the results. Such a system may never exist, but the fact that ethereum can sometimes change contract results means it isn't living up to its ideals.

Re: Critical Update on DAO Vulnerability

#586

Earlier quoted context omitted.

> No-one can write bug-free code Perhaps, but nobody can write a bug-free legal contract either, and no legal system is without bugs. Sadly, for the legal system, many of the bugs are due to corruption, so they are actually more akin to systematic exploits being done again and again by malicious actors (who often happen to be wealthy or powerful). Also, in terms of how drastic this bug is, suppose $5M gets stolen ove…

> Perhaps, but nobody can write a bug-free legal contract either, and no legal system is without bugs. The difference is that when there is an issue with a legal contract you can defer to an arbiter (a judge) and discuss whether that is a bug or a feature as soon as a divergence of interpretation is detected. Hell, even just having a sentient empowered human in the loop is sufficient, with fully automated response sy…

There's nothing preventing a contract from adding fallback modes that require interaction from human agents. Indeed, most of the more high-assurance contracts will probably require this.

Re: Critical Update on DAO Vulnerability

#588

anyway Ethereum feels like a cult. There's something weirdly disturbing for me about the ethos of blockchain technology, and how it jarrs with "The DAO" (note the capitalised definite article. There Is Only One. Hardly distributed or democratic). Also look at how a bunch of ethereum shills pack its "Curator", for which, by the way, The DAO is "incredibly privileged"[1]. What? Your own organization is incredibly privi…

It's arguable whether Etherium is a cult. The DAO is definitely a cult, with a cult leader.

Re: Critical Update on DAO Vulnerability

#590

Earlier quoted context omitted.

This is fascinating. How do ancaps propose that DRO's will enforce their judgments? With violence? What's to stop the losing party from just gathering a bigger militia and shooting back to prevent collection?

The most effective way is likely ostracism, or some other penalty based on reputation. If someone doesn't pay their debts, people just stop trading with them. I'd posit that most people are interested in restitution, rather than punitive measures, which would be the primary goal of a DRO -- making the victim whole again. This is why DROs would likely function similar to an insurance agency. The non-aggression princip…

> The non-aggression principle is a central tenet in ancap philosophy which would preclude violence in most cases, however, it is permitted in self defense of ones person or property.

What if someone disagrees with the non-agression principle or uses a very liberal definition of "self defense"? If I'm the only one who is permitted to use violence to defend myself, does this mean I have to carry a weapon with me at all times (and hope the other one doesn't have a bigger gun/has hired the more expensive security force)?

Post reply on HN