Are you using Solidity to develop smart contracts in Ethereum? Are you aware of the security alert released on the Ethereum foundation’s blog?
Solidity released version 0.4.4 on GitHub to fix a storage corruption bug, after the vulnerability was highlighted by GitHub user Catageek. The issue was about how, in certain situations, variables were overwriting other variables in storage. This opened up attack potential in some smart contracts, if they were written in Solidity version 0.1.6 to 0.4.3.
Ethereum’s blog post detailed the specific problem:
Storage variables that are smaller than 256 bits are packed together into the same 256 bit slot if they can fit. If a value larger than what is allowed by the type is assigned to the first variable, that value will overwrite the second variable.
This means if an attacker can cause an overflow in the value of the first variable, then the second variable can be modified. Creating an overflow in the first variable is possible using arithmetics or by directly passing in a value from the call data (values in call data are aligned to 32 bytes, and padding is neither verified nor enforced).
Contracts that only use the types listed below for state variables are not affected. Arrays, mappings and structs (based on those following types) are also not affected:
- signed integers, including sizes smaller than 256 bits
- bytesNN types, including sizes smaller than 256 bits
- unsigned integers (uint) of 256 bits
Contracts with types smaller than 256 bits that are never next to each other (note that state variables of base contracts are “pulled in”) are not affected.
The Ethereum multisignature wallet contract is not affected.
Note that addresses take up 160 bits, so contracts that only use addresses and 256-bit types are safe. Additionally, addresses and booleans are almost never manipulated via arithmetic operations in practice, so contracts using only addresses, booleans and 256 bit types should also be safe.
The following contracts may be affected:
Contracts containing two or more contiguous state variables where the sum of their sizes is less than 256 bits and the first state variable is not a signed integer and not of bytesNN type.
Types smaller than 256 bits include:
bool, enums, uint8, …, uint248, int8, …, int248, address, any contract type
The recommended actions for Solidity users are to update to the latest version (0.4.4) and recompile contracts that have not yet been deployed. If you have a vulnerable contract that’s already deployed, it’s recommended you deactivate the contract, remove the funds from it, or upgrade it using Solidity’s latest version.
Ethereum’s Christian Reitwiessner was vetting contracts for potential issues and concluded that “4 out of 12645 contracts exploitable by storage corruption bug, none critical.” So the good news is only a handful of contracts were vulnerable. The better news is Solidity 0.4.4 has removed the bug entirely.