Commentary on the recent DAO audit

  • It would have been additional UX design and front end implementation work, and we were short on time
  • It could have been abused to make malicious function calls if the voters didn’t pay attention to all the function calls a proposal makes
  • A final, clean audit report — which we couldn’t get due to audit scheduling difficulties — would have been nice to have for such a critical contract
  • I was suspicious about the multicall functionality being walled off successfully at the front end (because even though I reviewed that work, I was stretched particularly thin at the time)
  1. The attacker creates a proposal with an EVMScript that makes two function calls, the first one looking innocent and the second one being malicious. They set the metadata to make it seem like the proposal is created using the dashboard to only execute the first function call. To the voters, the proposal seems like it would only execute the first function call, causing the proposal to be passed and the malicious function call being executed.
  2. The attacker creates a proposal with an EVMScript that makes one malicious call, but the additional data they provide in the metadata makes it seem to be innocent (for example, metadata may state approve(address,uint256), while the function called is transfer(address,uint256)). Again, this causes the proposal to be passed and the malicious function call being executed.

--

--

API3 core technical team lead

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store