Deconstructing the DAO Attack: A Brief Code Tour

http://vessenes.com/deconstructing-thedao-attack-a-brief-code-tour/

by bpierre • 10 years ago

253 158 10 years ago

jacquesm10• 10 years ago

Whoever thought it was a good idea to have case sensitive function names where the names are allowed to be identical but not identical in function?

Major fuck-up there.

That should have never passed the concept stage, nor the review stage.

Function names should describe what a function does.

revelation• 10 years ago

What a shitshow. These people don't need "advanced static analysis tools" [1], they need a big old bag of clue.

1: Developers, cryptographers and computer scientists should note that any high-level tools (including IDEs, formal verification, debuggers, symbolic execution) that make it easy to write safe smart contracts on Ethereum are prime candidates for DevGrants, Blockchain Labs grants and String’s autonomous finance grants.

ethbro2• 10 years ago

OpenSSL had some code cruft too, and god knows that didn't stop it from being deployed in production. People use code because it works, not code that's perfect.

_pdp_• 10 years ago

Especially in code that supposedly describes contracts.

buttershakes• 10 years ago

I couldn't agree more with this sentiment. I haven't spent too much time on Ethereum contracts but this is such a ridiculous language/platform design issue.

semi-extrinsic• 10 years ago

Funny thing is, it reminds me of implicit typing of int/float based on the first letter of the variable name that ye olde FORTRAN77 had as a major footgun.

draw_down3• 10 years ago

The problem is deeper, this idea of contracts enforced by computer code written by humans ( = full of bugs) is a dumb one.

krisives• 10 years ago

Just because some smart contracts fail doesn't mean they all have to.

charonn0• 10 years ago

Are we sure that case sensitivity is the culprit? As others have noted, the function being called takes (and is given) 3 arguments but the function that is supposed to be called takes only 2.

jacquesm10• 10 years ago

IDE and autocompletion could be the direct cause, but in the end if the function had been properly named it wouldn't have happened (root cause).

rbobby• 10 years ago

Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans.

Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in case would get their approval?

And don't even get me started on filenames that only differ by case. If that's a good idea then I think trailing whitespace should be significant too!!!

jsprogrammer4• 10 years ago

IsTheOne() and istheone() are different bits of code.

kartickv9• 10 years ago

I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case.

I upvoted you.

pmontra• 10 years ago

There are languages that use lowercased names for constants (Erlang's atoms) and uppercased Names for variables, which are immutable and quasi constants anyway. This is uncommon but many other languages use uppercase for classes (Person) and lowercase for variables such as Person person = new Person(). That last example is one reson for having case sensitive languages. I can't think of any language I used in the last 30 years that was case insensitive. Maybe some BASIC interpreters on home computers in the 80s? But not all of them had upper and lower case characters to start with.

Linux has a notoriously case sensitive file system, with trailing significant spaces (they are not special characters). Mac and Windows also have case sensitive file systems but that feature is turned off by default.

bzbarsky• 10 years ago

For any language that allows non-ASCII identifiers, trying to define "case insensitive" is a minefield best avoided. For example, with general Unicode characters, "case-insensitive" comparison doesn't give you an equivalence relation on identifiers because transitivity fails.

Of course you can define things to be case-insensitive only in the ASCII range, and treat your non-ASCII stuff as second-class citizens...

willtim13• 10 years ago

Modelling financial contracts in an imperative event-driven paradigm just seems like an accident waiting to happen.

EDIT: To the downvoters, if you disagree, I would very much like to understand why, please reply with a comment.

EDIT2: My position is that it is very difficult to reason about correctness and maintain invariants in a highly imperative setting. IMHO, it would be more desirable to use a declarative, or functional language. There are many successful commercial applications of functional programming to financial contracts, e.g. Lexifi, which is based on a subset of OCaml and various in-house solutions developed by banks. Using a functional programming language would also mean the code is far more amenable to formal methods and static verification. One new startup I was very impressed with, aestheticintegration.com, has had success rewriting financial algorithms in a functional programming language in order to prove and verify numerous correctness properties about them. It is a huge shame that folk do not reach straight for the functional programming toolbox when faced with these types of problems.

rahimnathwani• 10 years ago

I didn't downvote you, but your comment left me scratching my head. You made a statement without any explanation. Care to elaborate why imperative programming is so bad here? Real-world contracts also use imperative style.

jacquesm10• 10 years ago

This code is very bad, without going into an exhaustive enumeration, case sensitive function names, variables with unclear scope all over the place and so on.

That it's imperative code is something that I don't think is damning by itself but all the side-effects (including side effects based on a single bit in the name of a function) really do warrant the 'accident waiting to happen'.

chii• 10 years ago

real world contracts are interpreted by a court of law, which have leeways that aren't afforded by a machanical interpreter.

Waterluvian• 10 years ago

Same to you. Can you explain why you think so?

willtim13• 10 years ago

I've tried to explain my position briefly above in an edit.

tmalsburg24• 10 years ago

This is the most insightful comment about this incident that I have seen so far. The problem is that the Etherum system uses an imparative language to describe smart contracts. This opens the door very wide for the kind of bugs that led to the theft of $200M from The DAO. The correct solution would probably have been to design a domain-specific declarative language that provides abstract building blocks for smart contracts. This would have allowed to hide the procedural complexity in the interpreter and contract bugs like the present one would not have been possible. Even if there was a problem, it could likely be fixed in the interpreter leaving the contracts and the blockchain untouched! This means that a lot of unanticipated problems would not have been fatal for the contracts. The problem of the current approach is that it conflates the business logic and it's implementation thus increasing the burden for contract authors and increasing the attack surface.

In many other domains, a suboptimal choice of language paradigm would just add some extra friction but in the domain of smart contracts it can lead to catastrophic failures. Many people claim that the cause of the present disaster is just a faulty contract and that the Etherum system is working correctly. Some even say that the present case shows how well the technology is working. But willtim's comment makes it clear that there may be a fundamental problem with Ethereum. I wonder whether the imparative paradigm was a conscious design choice or something that just happened because the developers didn't even realize that it was a design choice.

Edit: I wrote this before willtim's added his edit 2.

pron9• 10 years ago

I think you are placing far too much emphasis on language, especially as so far there's little evidence that some programming approaches yield less logical errors than others. I often see a similar sentiment expressed by people who are familiar with functional programming but unfamiliar with software verification, and may be unaware that nearly all verified software in the industry is written in imperative languages. I know many FP people like to believe that the local guarantees made by their chosen languages end up making their programs more globally correct; it may well be true that some languages make some errors easier to spot for humans (although we have little evidence to suggest that this is indeed the case of FP). However, as far as formal verification is concerned, there is very little overlap between verified software and FP.

Ensuring correctness -- i.e. conformance to a specification -- is, in general, a task that requires effort -- by man and/or machine -- proportional only to the complexity of the algorithm verified (i.e., the number of states reachable by a TM implementing it) and almost not at all to some linguistic properties. That is not to say that languages cannot prevent local errors that may be catastrophic, but the difference between the best of languages and the worst of languages when it comes to verifying spec-compliance is not that big.

Using a functional programming language would also mean the code is far more amenable to formal methods and static verification

That is not true. If anything, imperative languages have better formal verification tools than functional ones. And besides, for global program "correctness" properties, the choice of a language more or less amenable to formal reasoning may make a difference that is surprisingly small.

mbrock2• 10 years ago

I agree that functional vs imperative is a red herring in this case.

The Ethereum model is "imperative" anyway, so a functional DSL would probably end up looking like some kind of monad.

That said, it seems interesting to use a language like Agda for writing a DSL to EVM compiler, regardless of the exact nature of that DSL. Then you can have machine checked compiler correction proofs and also prove theorems about DSL programs.

willtim13• 10 years ago

Of course most of the money has been funding tools for imperative languages as that is the status quo. But this does not prove that there is little overlap with FP. Research FP languages like Coq have enabled INRIA to build a fully verified C compiler (Compcert), can your tools accomplish this? As far as Europe is concerned, FP does appear to be the future of formal verification.

johnbender• 10 years ago

I would go further.

Given the sums of money involved I think it might also be worthwhile to have a formal semantics and a logic for proving safety properties of these blockchain programs (beyond type safety).

Not every application would require that kind of rigour but if the participation and value of a given currency/contract/program is determined largely by trust then it seems natural to want more serious guarantees.

willtim13• 10 years ago

I agree. I covered this only briefly under 'formal methods'. My point was that such formal semantics and proofs are far more easily obtained starting from a functional language.

mietek• 10 years ago

Note that a type system, if done properly, is simply another name for a logic for proving properties of programs.

Examples:

* Agda (http://wiki.portal.chalmers.se/agda/pmwiki.php)

* Coq (https://coq.inria.fr)

* Idris (http://www.idris-lang.org)

jwr• 10 years ago

I partially agree — e.g. yes, declarative specifications would have been better. But having looked at some of the code, it's just poor quality. Bad code, plain and simple.

If you write bad code, you will eventually get bitten. If you use bad code to build a financial institution with great claims, it will also cost you money and reputation.

Bad engineering has consequences.

devit• 10 years ago

The actual issue is the fact that sending money to someone can result in untrusted code running in the middle of your code execution and even reentering it seems absurd.

Sending should always succeed immediately and if anything needs to be automatically triggered in response, the trigger should be executed asynchronously.

A great way to immediately see the problem is, for anyone with Rust experience, to think of this as a function taking an &mut self being somehow reentered without that &mut self being passed out by the function itself.

vessenes3• 10 years ago

I completely agree. There seems to be less appetite for this than I would have imagined. A rich type system is absolutely going to be a huge help for smart contract authoring.

fabled_giraffe5• 10 years ago

I know I'll get napalmed for saying this, but why is this all over HN? Why are people obsessed with cryptocurrencies?

It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off?

Since we've determined over history that some people will take advantage of weakness for their own gain, no matter what system you create to transfer goods, resources, services or value representing those, it will be exploited. So- why even spend time on it?

If everyone who cares to maintains their own accounting data does so, regardless of what technologies we are using, we really could just trade in goods, services, and coin and completely get rid of all virtual currency. Investments could go back to literally to providing coins, goods, resources, or services to those that we'd like to support possibly in exchange for reciprocity.

Since that won't happen right away, if you really want to secure your financial future, major S&P 500 index tracking funds have been one of the smartest things over its history to invest in: http://finance.yahoo.com/echarts?s=%5EGSPC+Interactive#symbo...

While some of you made money on bitcoin, many lost. Now the same game has been played again with people believing that someone can write code to replace our currency system and if they get in early enough, they'll be kings or queens. Well- again, it didn't happen. What really is to gain from this fantasy world of cryptocurrencies? It is harming more than it is helping, from what I see.

And if you downvote this, tell me why, otherwise I'll just assume you are with those that want to exploit me and others.

TazeTSchnitzel• 10 years ago

I know I'll get napalmed for saying this, but why is this all over HN?

Because the DAO's failure is interesting.

draw_down3• 10 years ago

And funny!

martinko• 10 years ago

Now the same game has been played again with people believing that someone can write code to replace our currency system and if they get in early enough, they'll be kings or queens.

Is that all you see?

Decentralized currencies, ethereum and DAOs are fascinating from a technological standpoint. This is major news in the field of smart contracts, which are related to both programming and technology. How could this not be posted here?

yankoff• 10 years ago

So we should just stick to our current currency system forever? Why even bother trying to invent new things if they fail sometimes?

jacquesm10• 10 years ago

Why are people obsessed with cryptocurrencies?

Because they are interesting in a theoretical way and because real world implementations are even more interesting, they show us what the future might look like.

It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off?

That's not the intent.

Since we've determined over history that some people will take advantage of weaknesses for their own gain, we should assume that as a given until proven otherwise.

Agreed.

No matter what system you create to transfer goods, resources, services or value representing those, it will be exploited.

That remains to be seen. There is an outside chance that it is possible to create something solid, my guess is that it will have to be something extremely simple.

So- why even spend time on it?

Just like it took a while to map the globe, mapping this 'space' takes time - and effort - and funds. I'm fine with it, it isn't my time, my effort or my funds and I end up learning just as much as those that put forward their resources. Think of it as free education on someone else's dime. That's a pretty cynical view but to date I have not seen any system that appears to be solid enough to warrant backing.

If everyone who cares to maintains their own accounting data does so, regardless of what technologies we are using, we really could just trade in goods, services, and coin and completely get rid of all virtual currency.

That would severely limit the amount and kinds of trade possible. On the other hand, a really strong cryptocurrency has risks all its own and it is worthwhile to consider the downsides with the upsides.

DrJokepu• 10 years ago

That remains to be seen.

Isn't this a somewhat meaningless statement? Is it possible to prove that "no matter what system you create to transfer goods, resources, services or value representing those, it will be exploited"? Is it possible to prove the contrary (that there is or could be such a system)?

It will never be seen because we will never know for sure one way or the other. Best we can do is to make educated guesses based on past experiences.

huuu• 10 years ago

I agree that greed is a world wide problem. But even when we trade in goods services and coins it doesn't change the fact that a lot of people are greedy.

This is on HN because this story is interesting from a technical point of view.

xenophonf• 10 years ago

Even though I disagree with some of your conclusions, I personally have no problem with your comment except for the very first and very last sentences. I generally downvote people who complain about submissions or about their comments being downvoted, which I view as unproductive.

dhimes• 10 years ago

I feel the last sentence, unfortunately, is relevant. Too many people now just downvote without explanation, and that is not helpful to the conversation. In something like this, which is a question disguised as a rant or vice versa, an explicit request is, unfortunately, necessary today.

irln2• 10 years ago

Because it is an insanely interesting problem to try and solve technically.

That is, a medium of exchange is essential to a modern economy and yet how to objectively regulate the supply of that medium of exchange without exploitation can be considered somewhat of a paradox. The quest is to solve the paradox via ever evolving technological solutions.

vezzy-fnord• 10 years ago

objectively regulate

There's your problem. Such grandiose visions might have passed for a 1930s-era technocrat, but are laughable today.

TruthAndDare• 10 years ago

It's bad enough that those with sufficient computing speed/power can already rip off the stock market

Who is getting ripped off?

tdaltonc4• 10 years ago

Any one who agree with the narrative outlined in Flash Boys (which I do), thinks that HFT is basically a drain on the economy. It doesn't help allocate capital more efficiently or provide any liquidity when it's actually needed. It uses speed and deliberately rigged market rules to take returns fro people that are trying to put capital to work (either as investors or as businesses).

verroq• 10 years ago

Because we missed the boat and we hope the boat sinks.

Search your feelings, you know it to be true.

tinco3• 10 years ago

I think maybe you're a bit confused about what HN is, it is a community that gathers and discusses news that is relevant to people who are starting or funding new companies, mostly in the information technology sector.

Cryptocurrencies attract money and spawn companies, there are YC funded startups that are based around cryptocurrencies. If you're looking for refuge from them, you've gone to the wrong place, this is basically the lions den. If there's money to be made with technology, this is where it'll be discussed, no matter over whose back.

Just that it's on HN doesn't mean HN or even YC supports it. If everyone on HN would support ETH, BTC or the DAO, it'd be worth even more. It's just interesting technology with relevance to business and finance.

fabled_giraffe5• 10 years ago

it is a community that gathers and discusses news that is relevant to people who are starting or funding new companies, mostly in the information technology sector.

Been here since 2007 off and on. Usually don't use same user because I quit HN periodically due to philosophical differences, and I don't care about HN user karma or the ability to downvote.

It's been my experience that people here have many interests, and debates of we should be exploring certain avenues and why we obsess over things are just as valid as any other.

ghamrick• 10 years ago

I don't participate in virtual currencies because I am not smart enough to understand all the nuances, or at least I don't take the time to try and understand them. Plus, I don't have money to throw away. However I find the discussions about the DAO fascinating because of the intersection of technology, law, ethics, morality and government.

Atwood2• 10 years ago

I do not denounce your assertion(s), but, I would like to read how you apply them to Ethereum. To me, the literature seems very much to be attempting to prevent from baking in our (human) duplicitous nature, opting instead for an almost forced virtue. Please suffer a fool and expound/expand for me?

wyager3• 10 years ago

That is extraordinarily pessimistic and rather short-sighted, to be blunt. The point of cryptosystem-based financial tools is that they're more... raw than the normal financial tools we have access to historically. They work by a much stricter set of rules. This means it's easier to mess up and lose money, but it also means they're more efficient, predictable, and equitable.

The existing financial system is inextricably entwined with our political and legal system. This is both good and bad. Bitcoin, ethereum, etc. are efforts to make financial systems that are independent of politics and central management. In my opinion, Bitcoin has done a much better job, because it's actually reasonably decentralized and they don't change the rules whenever people get their money stolen.

fabled_giraffe5• 10 years ago

I'm sorry for violating an HN guideline by saying "I know I'll get napalmed for saying this". I was not aware of that guideline, and have been in the HN community for about nine years now.

jhildings• 10 years ago

It's a very interesting combination of a lot of HN related subjects. Like networking, cryptoanarchism, decentralisation , computer science and scaling problems, cryptographic solutions and finance platforms.

What not to like about reading about news and opinions about this ? I find the current obsession with deep learning/AI here much more uninteresting

And also, just read the first word of the name. HACKER news, which is very self explanatory

jcfrei• 10 years ago

So, this review makes me wonder: Will the hard fork of the ethereum blockchain be of any use at all? The DAO appears to be fundamentally flawed, are all the coins there simply lost? What prevents an attacker from exploiting the DAO after the hard fork? Or will they simply invalidate all the transactions that went to the address of the DAO?

tdaltonc4• 10 years ago

As I understand it: The goal of the fork is to freeze the DAO account starting just before the 'split' drain (at the blockchain level). And then figure out a long term solution (possibly using another fork to return all ETH to the original contributing accounts dissolving the DAO?).

The ability of a core of developers and miner to exercise their will over the system like this is alarming though.

https://blog.ethereum.org/2016/06/17/critical-update-re-dao-...

altern8tif• 10 years ago

So all this hoo-ha is really just because of a capitalised "T"? If the code were fixed, is the DAO model still valid in the real world?

(I'm a cryptocurrency noob... Some of technical stuff just went over my head)

kolinko• 10 years ago

The real question is whether smart contracts can ever be safe enough so that they have real world applications.

seibelj• 10 years ago

Bored computer scientists: analyze contracts that are less popular but still have money attached to them and see if you can locate a bug. Apparently you can get the money legally and the only way to stop you is to hard fork the entire currency.

homero• 10 years ago

Glad I never touched alts. My bitcoin are safe and increasing

tinco3• 10 years ago

In addition to this the language is not explicit enough. Even standard Haskell wouldn't be safe enough for a program that manages $250MM directly without safe guards.

In addition to typesafety, it would have to be both explicitly typed at the lowest possible granularity and annotated with pre and post conditions.

Not only did this code allow a bunch of tokens be transferred without compensation, it left the whole accounting system in a corrupted state! One that could have easily been detected and verified at any point.

This line:

    ```
        Transfer(msg.sender, 0, balances[msg.sender]);
    ```

Should have looked like this:

    ```
        // postcondition: balances[msg.sender] == 0
        Transfer(msg.sender, 0, balances[msg.sender]) :: Action<Transfer>;

    // Compiler result:
    // # Error 1: line XX expected type Action<Transfer> but instead got type Transfer
    // # Error 2: line XX violates postcondition, expected balances[msg.sender] == 0, got balances[msg.sender] != 0
    ```

And the whole function 'splitDao' should have a type annotation that completely captures the possible actions it might encompass, and pre- and postconditions that at the very least constrain the result of the function to not corrupt the accounting of the DAO (i.e. it should still have as many tokens as it believes it has).

It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff and its importance in high reliability systems. He should have known the contract language should have had typechecked side effect and he should have known proper pre- postconditions would have been the least he should have done.

tmalsburg24• 10 years ago

One solution might be to design a safe language that compiles to the the language used in Ethereum. Not sure if possible within the given constraints.

eudox• 10 years ago

The problem then becomes ensuring that only code compiled from that language can run.

krapp• 10 years ago

Wouldn't it be better to just rewrite everything in that safe language and abandon whatever Ethereum is written in?

whazor2• 10 years ago

To counter your attack on Buterin, he is aware that writing safe contract code requires proofs and type safety. That is why solidity is compiled to EVM code, so that improved languages could incorporate this. Solidity is built for rapid innovation and user friendliness. Buterin is now more busy with sharding and scaling issues.

powera• 10 years ago

People did lose $200 million dollars. Why is he focusing on scaling?

Edit: apparently the thefts so far are "only" 45 million.

jacquesm10• 10 years ago

Buterin is now more busy with sharding and scaling issues.

Those are currently not the issues that require attention.

You can make it as fast and as large as you want, if it is broken at the root that's all pointless. First walk, then run. I'd be more impressed with a much smaller system without sharding and massive scaling properties if it was bullet proof.

egg_head2• 10 years ago

When I had my own start up companies or worked for those of my friends, we ensured that the first few sets of big customers got white glove treatment from the executive team....

This is what happens when one does not do that. :)

dang3• 10 years ago

It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff

Personal attacks, which this crosses into, are not ok on Hacker News. Please edit such stuff out of your comments here.

We detached this subthread from https://news.ycombinator.com/item?id=11928562 and marked it off-topic.

tinco3• 10 years ago

Hi Dang, my apologies, I can no longer edit the comment, please feel free to snip that paragraph out.

I guess I felt the need to accuse someone as I felt frustrated. News like this really smears not only cryptocurrencies but software engineering in general. A single typo cost these people $50M is what they claim, but the reality is that the whole system was recklessly engineered. I guess I'm also saddened that so much money was put behind something that was so clearly recklessly engineered.

Would it been a crazy idea just to invest a million or two of the $250M to pay a Formal Methods team at any university in the world to give the language a quick do-over?

kartickv9• 10 years ago

FWIW I didn't interpret this as a personal attack, but as a critical contribution to this discussion: We can't have financial software built by 22-year old dropouts. A new social network? Sure. A game? Sure. A todo list app? Sure. Financial software? No.

If it was phrased as "person XYZ is an asshole!" then I would agree that it's a personal attack.

egg_head2• 10 years ago

He is stating facts, except for the last clause which is an opinion which does not apply to the main subject.

pmoriarty• 10 years ago

"It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff and its importance in high reliability systems."

I wouldn't be so hard on the kid. Now, the due diligence that should have been performed by the corporations that sank millions in to this project, who actually do hire plenty of people who are well educated and should have known better is another matter.

But I suppose jumping in early in to the tulip craze and riding it for all its worth is more important than taking the time and effort to make sure the system is reliable and robust before it goes live.

vessenes3• 10 years ago

Well, Dr. Chris Reitwiessner is in charge of the solidity project I believe.

I have been told he's not big on functional / richly typed systems, but I don't have any actual knowledge.

winteriscoming3• 10 years ago

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught this bug, isn't it? After all, the test case would have checked for the balance etc... after execution of these functions. Aren't there any test cases around this?

niftich• 10 years ago

I couldn't follow that Transfer vs transfer call either; the number of arguments don't match, and I don't know where 'amount_' comes from.

The code is exceedingly painful to read, and makes me wish I had been involved in this effort before it made the news. I can't help but think, lack of unit tests aside, is this the first time they're running this code? What sorts of decision-making led to this outcome? I want Hanlon's razor to apply but given the amount of money involved, I am not entirely convinced.

winteriscoming3• 10 years ago

If I understood the explanation on that article correctly, what's even more interesting is that this typo apparently hasn't yet been fixed in the repos (assuming I'm looking at the right ones).

There are 2 repos which I looked at:

https://github.com/slockit/DAO

https://github.com/TheDAO/DAO-1.0

I don't know which one is the authoritative one. But the interesting bit is both these repos still have that same typo in the master branch:

https://github.com/TheDAO/DAO-1.0/blob/master/DAO.sol#L666

(the other repo) https://github.com/slockit/DAO/blob/develop/DAO.sol#L685

The slockit account repo has a commit which was made 6 days back, with the commit message "Protect against recursive withdrawRewardFor attack" https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... but it doesn't fix the typo and there aren't any more commit in there after that one.

Does this mean, the upstream repos containing the typo haven't yet been fixed? Or am I just looking at the wrong repos/branches? Or did this typo get known only a few hours back?

legohead• 10 years ago

This is what I wanted to ask about. I don't even know what language this is. Is Transfer even a legit function, and if not, does this language just keep on chugging for non-existant function calls?

thoth• 10 years ago

The language is Solidity (https://solidity.readthedocs.io/en/latest/) which runs on the Ethereum VM.

Certainly one of the challenges for the project is implementation and security issues in the Turing-complete language they decided to create for the purpose of smart contracts. Postscript and ActionScript have probably averaged a security flaw a month for the last decade; I can't imagine getting Solidity correct from the start.

vessenes3• 10 years ago

I think after sleeping on it that I agree with you, this is more likely the outcome of bad refactoring. You can read the code commits on github if you like; I don't have them handy, unfortunately.

transfer is a very poorly named function, of that there is no doubt. And Transfer is badly named as well.

transferAndLockTokens vs LogTransfer would be much, much better.

rrradical• 10 years ago

Test cases...code review... How about type checking??

The idea of writing financial software without taking every available precaution to verify correctness is insane to me.

wyager3• 10 years ago

This is why Fintech groups are some of the biggest users of strongly typed functional languages (ocaml, Haskell, etc). Your insane-o-meter is working.

vatotemking• 10 years ago

One of the hardest things in computer science: naming things

harmegido• 10 years ago

I'm curious, are there no tests for the code running this? It seems like some of these bugs would be caught with them (especially the typo). And it seems like insanity to not have them.

htns2• 10 years ago

I don't get how the transfer vs Transfer typo is supposed to have enabled a larger attack. The token balance is zeroed in the splitDAO function anyway, and presumably the sanity checks in transfer are also redundant, or else there would have been no need for recursion.

RobertoG• 10 years ago

I'm going to be a little polemic here.

It's this an attack?

It's not the problem that those technologies try to solve, to get rid of subjectivity?. In a way, this could be interpreted as trying to be free of politics.

If my understanding of what they are trying to accomplish here is correct, if the system allow it, then, by definition, it's legal.

If you require a framework where something allowed by the code but with unexpected consequences is illegal, you are again where you started.

wyager3• 10 years ago

You're being thoroughly downvoted, but I don't see anything wrong with your argument. The person who pulled off this "hack" was following all the rules. In fact, I could even see the argument that by undoing this transaction, the people who started the DAO are in fact going back on their word. They promised that they would build a system which would obey certain rules. By undoing this transaction, they are no longer following those rules. Now, obviously there's a strong argument for rolling back the transactions, but at this point ethereum has lost any claim to objectivity or decentralization.

developer2• 10 years ago

> obviously there's a strong argument for rolling back the transactions

Absolutely not. Such an act would entirely destroy the credibility of the entire system and its future. If not rolling this back is detrimental to the system, then it has already failed and should be dismantled. Who would continue to use a blockchain that permits such a thing? It completely defeats the purpose.

beachstartup• 10 years ago

if you could 100% accurately and reliably model a contractual understanding in any kind of language, it would have been done eons ago. human language (i'm fond of english in particular), is extremely expressive.

but there's a reason we still have courts and judges. it's because language is the tool through which humans express their desires and fears (computer language included, because it is written by humans, so far), it's not a machine.

tdaltonc4• 10 years ago

I don't think that there was any pressure to deeply formalize contrasts before this because even if you did, there would still be recourse to a human judge (not just a compiler). If one party didn't like the strict reading they could sue.

The question that's playing out right now is "is there human judge behind the code." If a set of humans (miners and developers) successfully overrule the code, this will seriously undermine the whole premise of this project.

tdaltonc4• 10 years ago

It looks like this is a typo. The question is, "does that matter?" It seems to me that either the code means what it says, or it doesn't. If a cabal of humans are able to overrule the machines, then what is the point of Etherium? Wouldn't we just be trading one group of authorities for another?

I want to see Etherium work, and it is extremely unfortunate that basically THE first high profile smart contract has gone sideways. But I'm not sure if I want there to be anything we can do about it. The whole point of this project is that the blockchain is supposed to be like an indifferent force of nature.

amaks• 10 years ago

The biggest problem I see with the code at https://github.com/slockit/DAO/ is absense of the unit tests. The code looks complex, how the hell can you make sure that it's right?

The Solidity wiki doesn't have a single entry on testing either:

https://github.com/ethereum/wiki/wiki/The-Solidity-Programmi...

graup• 10 years ago

The repo you linked does have a "tests" directory. It contains "scenarios", so not really unit tests.

You can't really unit-test contracts at the moment.

lordnacho• 10 years ago

It reads like the debugging that you've done a million times if you are working with ordinary, mutable, C-family code.

To start off with, you think you're developing a valuable skill in being able to follow a call stack along with a bunch of variables. It certainly has its uses, but after a while you come to wonder why it always ends up this way. Sure, you can understand every bug eventually, but surely there's some reason why you're constantly reasoning about the state of the variables and the order of the function calls. You can write unit tests, but of course you can't think of all the undesired behaviours beforehand.

The author does mention that something functional with strong types is necessary. Probably a good idea.

As for the split function, there's a question of whether it is really necessary. I wouldn't have thought an investment fund would need a split function. An ordinary fund doesn't; if you're in, you're in for whatever proportion that you've put in. Why not just make a second fund with the same (reduced) code if you have some other group of investors? More functions = bigger attack surface.

winteriscoming3• 10 years ago

This function will reduce user balances, before the vulnerable withdraw function is called. So, instead of the logging function, we should have:

if (!transfer(0 , balances[msg.sender])) { throw; }

This would <snip>.... also reduce the tokens available to the user later on

The more I think of the typo and the explanation about it in that article, the more unclear I am about that whole code.

Keeping aside this hack, for a moment, if that is indeed a typo and instead it should have called the lower case transfer method to really reduce the user tokens, then does this mean that all these DAO contracts (or whatever the right term is) that have been executed till date have been affected by this and as such the entire eco-system state was already messed up before this hack?

Nothing in that article suggests that this code flow, where this apparent typo is present, is applicable only for this specific hack.

caf• 10 years ago

No, because after the call to Transfer() and withdrawRewardFor(), it sets their balance to zero:

  totalSupply -= balances[msg.sender];
  balances[msg.sender] = 0;
  paidOut[msg.sender] = 0;

So the bug is only exposed if the recipient of the reward transfers out the balance during the execution of withdrawRewardFor().

In fact, to me it doesn't look like there's a typo at all there - the call to Transfer() was fully intended just to log the burning of the tokens that will be accomplished by the later lines setting the balance to zero. The bug is simply that the balance isn't adjusted before the attacker gets a chance to execute code.

htns2• 10 years ago

The top comment on /r/ethereum agrees with you on it not being a typo: https://www.reddit.com/r/ethereum/comments/4onbkj/deconstruc... . Hopefully in a few days we will have an authoritative explanation. Otherwise this might become a HN urban legend.

Deconstructing the DAO Attack: A Brief Code Tour

Related Stories