Security behind the MakerDAO governance contract upgrade
On May 07, 2019, Beijing time, blockchain security company Zeppelin issued a security warning to DeFi star project MakerDAO on Ethereum, claiming that there is a security breach in its governance contract, and hopes that users who have locked the voting will unlock MKR as soon as possible. . MakerDAO's developer Maker also confirmed the existence of the vulnerability and launched a new governance contract, claiming that the vulnerability has been fixed.
After the security threat was exposed, PeckShield tracked the transfer of MKR tokens and issued a warning to the community several times, calling on MKR token holders to immediately transfer the MKR tokens of the old contract. Up to now, most of the MKR tokens have been transferred, and there are 2,463 MKR tokens (worth about $1.28 million) in the old governance contract to be transferred.
On May 07, the independent research by PeckShield found that the existence of the vulnerability (we named itchy DAO), specifically: due to some defect in the voting mechanism (vote(bytes32)) implemented by the governance contract, Vote for a slate that doesn't exist yet (but includes a proposal that is voting). After the user votes, the attacker can maliciously call free() to exit, to reduce the legitimate votes of the valid proposal, and simultaneously lock the voter's MKR token.
On May 8th the following day, PeckShield Emergency and Maker Company synchronized the details of the vulnerability. On the morning of May 10th, MakerDAO released the new version of the contract. Zeppelin and PeckShield also independently completed their own audit of the new contract and determined that the new version fixes the vulnerability.
- ChainNode chain node successfully settled in bitcoin.org, opening a new era of Chinese blockchain community
- Babbitt Academy's 1st anniversary heavy upgrade! There are also Microsoft, Baidu, and Weizhong Bank for free classes for everyone! (There are benefits at the end of the article)
- The coin is stolen, and then talk about the ETS attack account of the Ethereum
Here we publish the details of the vulnerability and the attack method, and hope that other DApps that reference this third-party library contract can be fixed as soon as possible.
detail
In the design of MakerDAO, users can participate in their governance mechanism by voting. For details, please refer to DAO's FAQ.
Here are the details about itchy DAO. Users can lock and vote for MKR on their hands with lock / free:
After lock locks MKR, one or more proposals (address arrays) can be voted on:
Notice that there are two vote functions, the difference between the two is different (address array and byte32),
The vote(address[] yays) will eventually call vote(bytes32 slate), whose general logic is as shown below:
To put it simply, the two votes are the same, and finally call addWeight to put the locked ticket into the corresponding proposal:
Unfortunately, due to the mistakes in the design of the contract, the attacker has the opportunity to maliciously manipulate the voting result through a series of actions, so that the locked MKR cannot be taken out.
Here we assume that there is a hacker who has never voted to start an attack:
- Call lock() to lock the MKR, at which point deposits[msg.sender] will be credited to the locked amount.
- At this point, the hacker can pre-calculate the proposal to be attacked and pre-calculate the hash value, which is used as the pass parameter of step 3, because slate is actually just sha3 of the address array. It should be noted here that the selected target combination must not exist in slates[] (otherwise the attack will fail), and the hacker can also propose a new proposal to join the combination calculation, so that the combination must not exist.
- Call vote(bytes32 slate), because slate is actually only the sha3 of the address array, the hacker can pass the proposal before the line to pre-calculate the proposal to be attacked. At this time, because votes[msg.sender] has not been assigned, subWeight() will return directly. Next, the s3 that the hacker passed in will be saved to votes[msg.sender], then call addWeight(). From the code above we can see that addWeight() gets the proposal array through slates[slate], and the slates[slate] gets the same unassigned initial array, so the for loop won't execute (because of yays. Length = 0)
From the above analysis, we understand that hackers can cause the following possible effects through this attack:
1. Malicious manipulation of voting results
Second, because the hacker pre-deducted part of the votes, the real voter may not be able to unlock the lock
Timeline
PeckShield is the world's leading provider of blockchain data and security services. Business and media cooperation (including smart contract audit requirements), please contact us via Telegram, Twitter or email ([email protected]).
We will continue to update Blocking; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
- Compared to the adverse effects of restructuring Bitcoin, the loss of 300 million yuan is not a problem at all.
- There is no shortage of new gameplay in the currency circle.
- MatPool announced that it will formally join the Wanchain Galaxy Consensus PoS Node Program, which will soon be available on the WAN node pledge service.
- Encryption Currency Whale Deep Research: Manipulating the market is a misunderstanding, and there are people doing charity
- Getting started with blockchain: Mobile mining? Innovation or oolong?
- Future bets on DEX: Bancor, Kyber and 0x
- Encrypting World Investors: Drawing on Buffett's Ideas How to Cross the Bulls and Bears