calling `newContract()` to defeat the Quorum rule #78
3 participants
Yes this is potentially really dangerous, because as you say you can essentially move the whole balance of the DAO with only 20% quorum.
The only saving grace is that:
if (msg.sender != address(this) || !allowedRecipients[_newContract]) return;
makes sure that the recipient address is in the whitelist, so you can't just simply send it to just any user or yourself.
On the other hand if you collaborate with a contractor that is already in the whitelist and if you own at least 20% of the tokens you can rob the DAO of all funds.
@CJentzsch thoughts?
@colm The only way I see solving this (and any other attacks where a party of malicious token holders cooperates with a whitelist member) is to add the ability to remove an allowed address by implementing a removeAllowedAddress().
This way the curator can remove people who are attacking the DAO from the whitelist and effectively stop the attack.
I think that most importantly the quorum should never be bi-passed. removeAllowedAddress() may be useful for the guardian. But may open the door to abuse. But having addresses permently allowed does seem a little dangerous.
This attack is mitigated by the splitDAO and once the quorum abuse is prevented then it will just be a split case.
@colm yes all these attacks can be solved by splitting, but the problem here is that the lazy voters are no longer protected in any of these cases. If they don't get enough time to split they will lose all their money to the malicious whitelist member.
Got to look after the lazy voters. That is the responsibility of the guardian. So I would agree that a guardian needs a removeAllowedAddress() in some cases an malicious actor may end up on the whitelist. Thus they will need to be removed.
To what extent should we protect non-malicious white list members from a malicious guardian?
I added a the option for the guardians/curators to remove an address from the whitelist.
So in the case the curators are malicous and 51% of the token holder. Than you can't do anything to protect the apethetic voter.
Defeat the quorum rules by calling
newContract()with a users address sending a little gas to this contract and withdrawing all the ETH.totalSupply / minQuorumDivisor+(_value * totalSupply) / (3 * (actualBalance() + totalRewardToken));1Here where
_valueshould equaltotalSupplyas it is all ETH that is being moved. It will only equal the gas of the transaction. Thus what used to be a 51% attack becomes a 20% attack.