Closed howlbot-integration[bot] closed 2 months ago
MiloTruck marked the issue as not a duplicate
MiloTruck marked the issue as unsatisfactory: Invalid
There is no issue here.
If an operator calls deployVaults()
to deploy a native vault with slashStore == address(0)
, it will already revert.
Lines of code
https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/NativeVault.sol#L42 https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/CoreLib.sol#L85 https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/CoreLib.sol#L72
Vulnerability details
Impact
When deploying a NativeVault, asset address in the configuration struct(Operator input) can be zero according to NativeVault
initialization
functionAlso, protocol admin set allowlist(tokens that can be used as vault asset), which include setting up the slash Handler address, in the settings, zero address cannot be set up
From the above snippet, it shows that no slashHandler is set for
address(0)
. This is still making sense, since when deploying a NativeVault that accept address(0) as asset address the slash store is encoded asextraData
The cause of DOS here lies in the validation check when deploying vault. When a NativeVault is being deployed and asset address is zero, the function reverts
Proof of Concept
From previous observation, no slashHandler is set for address(0) in
allowlistAssets()
, this means if an Operator passes in address(0) as asset address with the aim of deploying NativeAsset, the deployment will revert!Tools Used
Manual review.
Recommended Mitigation Steps
Decode the extraData and validate that slash store address is not zero if the slashhandler is zero.
Assessed type
DoS