search

code-423n4 / 2022-07-swivel-findings

0 stars 1 forks source link

No Transfer Admin Pattern in Creator.sol, MarketPlace.sol and Swivel.sol #172

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Lines of code

https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Creator/Creator.sol#L47 https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Marketplace/MarketPlace.sol#L53 https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Swivel.sol#L428

Vulnerability details

Proof of concept: The current admin transfer pattern is calling setAdmin() function with an address type argument, which is immediately set to the new admin of the contract. If the new address of the new admin is actually not a valid account then the admin just got transferred to an uncontrolled account, breaking all functions that can be called only by admin.

Impact: this can impact availability of the protocol

Recommended Mitigation Steps: Implement a two-step process where the admin nominates an account and the nominated account needs to call an acceptAdmin() function for the transfer of admin to be completed. This ensures the nominated account is a valid & active one.

JTraversa commented 2 years ago

I've heard more folks recommend this sort of pattern recently but I'd really not consider it a med-risk, prob a potential QA suggestion?

bghughes commented 2 years ago

I've heard more folks recommend this sort of pattern recently but I'd really not consider it a med-risk, prob a potential QA suggestion?

Yes, I agree that this should be QA. Centralization risk is acknowledged and this is a "nice-to-have" sanity check IMO.

bghughes commented 2 years ago

This warden did not submit a QA report so this will act as it

robrobbins commented 2 years ago

swivel, marketPlace and creator all have setAdmin. vaulttracker sets the marketPlace at construction