In the MembershipFactory
, a vulnerability was identified in the mechanism used for managing upgradeable proxies through the ProxyAdmin
pattern. The issue arises from improper chaining of ProxyAdmin
contracts, which effectively disables the intended upgrade functionality of the TransparentUpgradeableProxy
. This malfunction will prevent the future upgrading of proxy contracts.
The flawed logic in the proxy administration setup stems from the following sequence of actions within the MembershipFactory
contract:
ProxyAdmin Initialization: The MembershipFactory
constructor creates an initial ProxyAdmin
contract (proxyAdminA
) with msg.sender
as the owner. This setup is supposed to facilitate control over proxy contracts for upgrades.
Creation of TransparentUpgradeableProxy: When deploying a new TransparentUpgradeableProxy
, proxyAdminA
is used as the initialOwner
input parameter:
In this setup, when a TransparentUpgradeableProxy
is instantiated, a new ProxyAdmin
contract (proxyAdminB
) is created with proxyAdminA
as its owner. Here's the relevant portion from the TransparentUpgradeableProxy
constructor:
This chaining means proxyAdminA
, which initially had msg.sender
as its owner, relinquishes direct upgrade control when proxyAdminB
becomes the actual admin of the TransparentUpgradeableProxy
.
Attempts to use proxyAdminA
for upgrading the proxy encounter issues because the delegated owner (msg.sender
) cannot directly interact with proxyAdminB
, which controls the actual proxy logic. The method upgradeAndCall
is the only callable function in a ProxyAdmin
contract:
Inability to upgrade the contracts
LOGS
Admin Address:
The Admin Address
0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
represents the intended admin, likely the deployer's address, or another address designated to control the deployment.
MembershipFactory ProxyAdmin:
The MembershipFactory proxyAdmin
is logged as 0x4f81992FCe2E1846dD528eC0102e6eE1f61ed3e2
.
This address corresponds to proxyAdminA
, which was initially created with msg.sender
as its owner, confirmed by the MembershipFactory proxyAdmin Owner being 0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
.
New DAO Membership and Proxy Chain:
The New DAO Membership Address
is 0xCB6f5076b5bbae81D7643BfBf57897E8E3FB1db9
, representing the deployed TransparentUpgradeableProxy
.
The Proxy Admin new DAO Membership
is logged as 0x3F919fAa6262122aeE2Db9EA8450321E5D5F2532
and is equivalent to proxyAdminB
, which is instantiated within the proxy and governs this new membership proxy contract.
Chained Ownership Breakdown:
The Proxy Admin new DAO Owner is 0x4f81992FCe2E1846dD528eC0102e6eE1f61ed3e2
, indicating that proxyAdminA
owns proxyAdminB
.
This owner relationship highlights the problem where the Admin Address
(0x7FA9385...) intends to control upgrades but is indirectly routed through a proxy chain (proxyAdminB
controlling the proxy, owned by proxyAdminA
).
Foundry
Instead of creating a new ProxyAdmin
and passing this as the initial owner to TransparentUpgradeableProxy
, the contract should directly utilize the address of the intended external administrator like the admin address.
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.