FUN Token Vulnerability is worse than Oyster Protocol

FUN is an ethereum token and today, someone discovered a vulnerability that is even worse than the one found in Oyster Protocol’s code. Anyone can check out its code on the Etherscan’s website, but here is the vulnerability.

Here is the code in question. This transfer function lets you transfer tokens to anyone but what is weird is fact that this actually calls into controller which is another contract. This means actual transfer can be done via another contract. Owner can set controller address.

function transfer(address _to, uint _value)
onlyPayloadSize(2)
returns (bool success) {
   success = controller.transfer(msg.sender, _to, _value);
    if (success) {
        Transfer(msg.sender, _to, _value);
    }
}    

However, the finalized property is set to false in the contract. What does this mean? It means that owner can set controller to anything.

function balanceOf(address a) constant returns (uint) {
    return controller.balanceOf(a);
}

In other words, you can create controller that will return any amount of tokens for any ethereum address. But that is not the scary part – you can create account with arbitrary amount of tokens – more than circulating supply.

How can FUN team fix this? They can do this by either finalizing FUN contract and by verifying controller code which FUN contract is tied to.