Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProtocolDAO.upgradeExistingContract does not perform the upgrade correctly. #542

Closed
code423n4 opened this issue Jan 3, 2023 · 3 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue duplicate-742 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-12-gogopool/blob/main/contracts/contract/ProtocolDAO.sol#L209-L216

Vulnerability details

Impact

The ProtocolDAO.upgradeExistingContract is intended to register a new contract in protocol and unregister the old contract. It essentially combined registerContract and unregisterContract function calls in a single call.

	function upgradeExistingContract(
		address newAddr,
		string memory newName,
		address existingAddr
	) external onlyGuardian {
		registerContract(newAddr, newName);
		unregisterContract(existingAddr);
	}

According to its implementation it can be seen that it first registers the new contract and then unregisters the old one. This sequence causes issues if the new and old name of the contract is same. In that case the storage values gets messed up.

Proof of Concept

contract BugTest is Test {
	Storage public store;
	ProtocolDAO public dao;

	function setUp() public {
		store = new Storage();
		dao = new ProtocolDAO(store);
		store.setBool(keccak256(abi.encodePacked("contract.exists", address(dao))), true);
        }

        function test_upgradeExistingContract() public {
        	string memory contractName = "Oracle";
        	address existingAddr = address(0x100);

        	dao.registerContract(existingAddr, contractName);

        	address newAddr = address(0x200);
        	dao.upgradeExistingContract(newAddr, contractName, existingAddr);

        	assertEq(store.getBool(keccak256(abi.encodePacked("contract.exists", existingAddr))), false);
		assertEq(store.getAddress(keccak256(abi.encodePacked("contract.address", contractName))), address(0));
		assertEq(store.getString(keccak256(abi.encodePacked("contract.name", existingAddr))), "");
        	assertEq(store.getBool(keccak256(abi.encodePacked("contract.exists", newAddr))), true);
		assertEq(store.getAddress(keccak256(abi.encodePacked("contract.address", contractName))), address(0));
		assertEq(store.getString(keccak256(abi.encodePacked("contract.name", newAddr))), "Oracle");
    	}
}

In the test case above, the newAddr address value points to "Oracle" string but the "Oracle" string points to null address.

Tools Used

Manual review

Recommended Mitigation Steps

Consider performing unregistering the old contract before registering the new one or consider validating that new and old contract names cannot be same.

@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Jan 3, 2023
code423n4 added a commit that referenced this issue Jan 3, 2023
C4-Staff added a commit that referenced this issue Jan 6, 2023
@c4-judge
Copy link
Contributor

c4-judge commented Jan 9, 2023

GalloDaSballo marked the issue as duplicate of #742

@c4-judge c4-judge closed this as completed Jan 9, 2023
@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Feb 2, 2023
@c4-judge
Copy link
Contributor

c4-judge commented Feb 2, 2023

GalloDaSballo changed the severity to 2 (Med Risk)

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Feb 8, 2023
@c4-judge
Copy link
Contributor

c4-judge commented Feb 8, 2023

GalloDaSballo marked the issue as satisfactory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue duplicate-742 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants