I'm writing a contract for an ERC20 token, based on Zepellin contracts. I noticed that their code doesn't handle the short address attack. Does it mean I shouldn't care about it?
There was a discussion about that.
Main reason is that it is a vulnerability of other contracts, and not token itself. It's their work to check all arguments. So yes, you should not care about it as token developer, but should care as contract developer).
-
If say an exchange interacts directly with the token contract's code, shall I assume that they do care about it? – ulu Dec 20 '17 at 20:12
-
1From my point of view there is no reason to take others' rensponsibilities. You can't protect everyone from shooting in a knee. – Andrey Putilin Dec 20 '17 at 20:35
-
1@ulu : I think this kind of mistake fell in the honeypot level : I mean it’s unlikely you’ll find an exchange with volume above 1000$ per day that would be still vulnerable (though it would be your self rewarding exercise to try a tiny withdraw check against each entry in that list). – user2284570 Jun 6 '18 at 20:53
Since solidity v0.5.0 it is not necessary anymore. From the changelog:
Code Generator: Revert at runtime if calldata is too short or points out of bounds. This is done inside the ABI decoder and therefore also applies to abi.decode().
Executing a function with less than required makes the transaction fail. Although you can send more data and it work, the extra data is ignored.
The short address attack is an user interface level issue.
It should not be addressed on the smart contract level.
The short address attack is mitigated on the user interface level by requiring all addresses to be checksummed Ethereum addresses:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md
If your (unnamed) multisig implementation user interface correctly checks for Ethereum address validity it is safe.