In LibDiamond.sol
library, the declared:
The hashed value serves as a unique identifier for the storage slot that holds the state of the proxy, which can be seen here in LibDiamond::diamondStorage
:
Same applies for the tractor storage:
However slots manually constructed using a string combined with keccak256
for hashing can be prone to storage slot collision as the hash value is known. This can allow potential attackers to relocate the storage slot location, using the same keccak256
method with additional crafted malicious payload.
Impact: High, as this can lead to storage collisions or in worst case an attacker can may find a potential path to these slots using keccak256
for hashing. Based on protocol's complexity, the damage it would cost is huge.
Likelihood: Low
Overall: Medium
Manual Review
It might be best, to subtract with by 1
, so that the pre-image would not be easily attainable. For example OpenZeppelin uses that technique:
in BeaconProxy.sol
: The beacon address is stored in storage slot uint256(keccak256('eip1967.proxy.beacon')) - 1
, so that it doesn't conflict with the storage layout of the implementation behind the proxy.
in ERC1967Upgrade.sol
:
Also here is a one reference link: https://forum.openzeppelin.com/t/calculation-of-proxy-contract-storage-slot/30745
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.