Simone Bronzini - Weaknesses of blockchain applications - Codemotion Milan 2018
•
0 likes•113 views
Due to the immutability of the ledger and the difficulty to update their consensus rules, Blockchain applications have many critical layers where a bug can cause huge, irreversible fund losses. This talk will shed some light on why and how Blockchain applications are so critical and will discuss past events that led to fund loss or consensus failures due to bugs in critical parts of the code of Bitcoin and Ethereum applications.
Report
Share
Simone Bronzini - Weaknesses of blockchain applications - Codemotion Milan 2018
- 1. Weaknesses of blockchain applications Simone Bronzini CTO @ Chainside How to shoot yourself in the foot playing with the blockchain
- 2. Summary 1. Blockchain recap: a. Immutability b. Consensus c. Smart contracts i. Turing completeness ii. Turing completeness consequences 2. A bunch of horror stories
- 3. Motivation
- 4. Main concepts We need a distributed ledger of all transactions. However: 1. How to disincentivise rewriting past history? 2. How do we make the ledger consistent across all nodes? 3. What does “owning/spending money” mean?
- 5. 1 - Proof of Work 1. A node gathers all proposed transactions in a block 2. It includes a hash of the previous block 3. It performs a computationally intensive work to find an appropriate hash of the new block 4. It broadcasts the block This guarantees long-term immutability
- 6. 2 - Consensus rules In any consensus-based system, nodes follow the same set of rules What happens if nodes follow different rules?
- 7. As soon as a blue block appears, there is no way to recover the split Hard fork
- 8. 3 - Smart contracts ● Code which defines the conditions to spend a transaction ● Are executed by all nodes in the network when validating transactions ● Can express pretty complex redeem conditions ● Examples: ○ Only the owner of private key matching public key K1 can redeem ○ Only the owners of private keys matching public keys K1 and K2 can redeem ○ Either the owners of private keys matching public keys K1 and K2 can redeem right away, or the owner of the private key matching public key K3 can redeem after 2 months from now ○ Providing the solution to the equation 3*x + 2 = 38 anyone can redeem
- 9. s3 Turing completeness - General concept s0 s1 s2 s4 s5 0, 1 0 1 0 1 0 1 0, 1 0 0 0 1 1 0 1 1 0 1 0 1 1 0 1 0... ...
- 10. Turing completeness - In real life
- 11. Turing completeness - Bitcoin formalisation s3 s0 s1 s2 s4 s5 0, 1 0 1 1 1 1 1 0 1 0 1 1 0 1 ... 0 s60 0 0 1 1 0 1 1...
- 12. Turing completeness - Bitcoin in real life
- 13. Turing completeness - Problems find the bug!
- 14. ● Classical software development process Turing completeness - Problems Development Testing Debugging
- 15. ● Classical software development process Turing completeness - Problems Development Testing Debugging Looks like all bugs are fixed...
- 16. ● Classical software development process Turing completeness - Problems Development Deployment Testing Debugging Looks like all bugs are fixed...
- 17. ● Classical software development process Turing completeness - Problems Development Deployment Testing Debugging Looks like all bugs are fixed... But then...
- 18. Turing completeness & immutability ● Software development process on smart contracts Development Testing Debugging
- 19. Turing completeness & immutability ● Software development process on smart contracts Development Testing Debugging Looks like all bugs are fixed...
- 20. Turing completeness & immutability ● Software development process on smart contracts Development Deployment Testing Debugging Looks like all bugs are fixed...
- 21. Turing completeness & immutability ● Software development process on smart contracts Development Deployment Testing Debugging Looks like all bugs are fixed... But then...
- 22. Turing completeness & immutability ● Software development process on smart contracts Development Deployment Testing Debugging Looks like all bugs are fixed... WHOOPS! But then...
- 23. Weakness surfaces NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 24. Now, a collection of horror stories...
- 25. Brainwallets ● Brainwallets are wallets that generate the private keys using few words chosen by the user as source of entropy ● With this technique users don’t have to securely store their private keys as they are able to regenerate them at anytime ● Unfortunately the lack of entropy in this key generation system makes it easy for attackers to brute force the private keys and steal the funds NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 26. Mt Gox ● In Bitcoin transactions are identified by their TXID, but unfortunately it was possible for third parties to change the TXID of a transaction without making it invalid ● MtGox used the TXID to track deposits and withdrawals of its users ● Attacker could request a withdraw, malleate the withdrawing transaction and contact MtGox support claiming that the transaction didn’t occur ● MtGox would then send a second withdraw transaction to the user NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 27. Bitcoin - Value overflow incident ● On August 15 2010, it was discovered that block 74638 contained a transaction that created 184,467,440,737.09551616 bitcoins ● This happened because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed ● A new version of the client was published, containing a soft forking change to the consensus rules that rejected output value overflow transactions NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER● The blockchain forked until the “good” chain eventually became the longest
- 28. Bitcoin - Multisig evaluation ● In its first version, bitcoin operation OP_CHECKMULTISIG expected N+1 values as an input to validate N signatures: 2 <pubkeyA> <pubkeyB> <pubkeyC> 3 CHECKMULTISIG Should be spent with: <sigA> <sigB> ● This meant: providing the correct number of signatures had the interpreter crash NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER ● The solution was actually easy (just provide one more dummy parameter): <null> <sigA> <sigB> ● To this day we still add a dummy parameter to multisig scripts
- 29. Bitcoin - 24 blocks long fork ● When version 0.8 was released, it used a new database engine: Level DB ● The previously used database was unable to process blocks that required more than 10.000 locks on DB rows ● As soon as such block was released, clients still using version < 0.8 saw that block as invalid, new clients saw it as valid ● A 24 blocks long fork resulted which was resolved when all nodes downgraded their software NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 30. Ethereum - Parity 1 ● Parity provided a multisig wallet smart contract which was probably overcomplicated (hundreds of lines of code vs. 2 <pubkey1> <pubkey2> 2 CHECKMULTISIG) ● In the contract there was a bug that allowed third parties to change the ownership of the contract, stealing the funds inside ● $31M dollars were stolen, and other $100M were taken by white hat hackers and later given back to the owners NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 31. Ethereum - Parity 1 NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 32. Ethereum - Parity 2 ● Parity multisig wallet contract refers to a library contract in the wallet logic ● The library contract however was actually an unutilized wallet contract, and it could be initialized by anyone ● Somebody did it, and as the new owner of the contract was able to kill it, freezing the funds of all the other wallets depending on it NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 34. Ethereum - DAO 1 ● The DAO was a complex Ethereum-based smart contract that was supposed to act as a decentralised investment fund and collected over $150M ● Due to a bug in its code, it was possible for an attacker to withdraw more money than deposited, draining funds out of the DAO ● The attacker stole $50M NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 35. Ethereum - DAO 2 ● To fix the issue, miners agreed to operate a hard fork and give the money back to the DAO investors ● As a result of the hard fork, the Ethereum network split and still today there are two incompatible versions of the chain NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 36. Bitcoin - Single transaction double spending ● September 2018, a bug was found that was introduced in PR #9049 (merged in November 2016) ● The bug allowed two attacks: ○ A miner could DoS a large part of the network (nodes would crash) (November 2016) ○ A miner could generate new BTCs out of thin air by spending the same output multiple times inside the same transaction (0.15.0, September 2017) ● It was fixed before anyone exploited it, apart from testnet NETWORK CONSENSUS CORE SMART CONTRACT INTERPRETER WALLET LAYER APPLICATION LAYER
- 37. Conclusions ● Blockchains are a very powerful tool, but: ○ Using them is very complex ○ Mistakes can cost millions ○ There is a huge need for experts ○ There is a huge lack of experts
- 38. If you feel like experimenting We released an open source Python3 library to create complex Bitcoin scripts: https://github.com/chainside/btcpy OR pip3 install chainside-btcpy
- 39. QUESTIONS?