Open code423n4 opened 2 years ago
Disagree with severity, in this case no pairs could ever be used because bytecode deployment would fail. No users would be harmed.
The medium risk label isn't just for leaked value. "Assets not at direct risk, but function/availability of the protocol could be impacted or leak value"
Given that 'function/availability of the protocol could be impacted', maintaining label.
Still, it's a nice workaround for the draconian eip-160.
Lines of code
https://github.com/code-423n4/2022-08-frax/blob/92a8d7d331cc718cd64de6b02515b554672fb0f3/src/contracts/FraxlendPairDeployer.sol#L170-L178 https://github.com/code-423n4/2022-08-frax/blob/92a8d7d331cc718cd64de6b02515b554672fb0f3/src/contracts/FraxlendPairDeployer.sol#L207-L210
Vulnerability details
In case of setting the creation code to less than 13K the creation would fail at 2 points:
BytesLib.slice(_creationCode, 0, 13000)
would fail sinceslice()
requires that_bytes.length
would be at leaststart + length
.SSTORE2.read(contractAddress2)
at_deployFirst()
would fail since calling this on address without code would cause a math underflow (due topointer.code.length - DATA_OFFSET
)Impact
In case the code of the pair gets smaller (e.g. optimization, moving part of the code to a library etc.) to 13K or less, it'd be impossible to set it as the new creation code (or in the case of the 2nd issue, it'd be impossible to deploy it)
Proof of Concept
In the following test I try to set creation code to a smaller mock pair. The test was added to
src/test/e2e/FraxlendPairDeployerTest.sol
:The mock pair was created as
src/contracts/audit/MockPair.sol
:Recommended Mitigation Steps
If creation code length is 13K or less:
BytesLib.slice()