Open c4-bot-5 opened 7 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as high quality report
This would indeed be an issue and extend beyond securing SCW deployment on various chains for the same address.
raymondfam marked the issue as duplicate of #46
raymondfam marked the issue as not a duplicate
raymondfam marked the issue as primary issue
This is working as intended. Users need to pass original owners in the same order to get the same address.
wilsoncusack marked the issue as disagree with severity
wilsoncusack (sponsor) acknowledged
User mistake with no impact other than purely UX - having to recreate the wallet with a different input order.
3docSec changed the severity to QA (Quality Assurance)
3docSec marked the issue as grade-a
This previously downgraded issue has been upgraded by 3docSec
(temporarily upgrading to to dedupe #114)
3docSec changed the severity to QA (Quality Assurance)
Lines of code
https://github.com/code-423n4/2024-03-coinbase/blob/e0573369b865d47fed778de00a7b6df65ab1744e/src/SmartWallet/CoinbaseSmartWalletFactory.sol#L28-L56
Vulnerability details
Impact
The same address list should give the same address based on the assumption that if the parameters passed are the same but the create account in the factory will deploy 2 different address if the same address are passed when the position of the address are switched with the same nonce. This error will break the already established fact that the same owners list and nonce should give the same address and revert without creating another account. But will not follow this assertion hence invalidating it. The impact of this issue is critical as it undermines the expected behavior of the system regarding account creation. Specifically, it disrupts the deterministic nature of account address generation, potentially leading to confusion, data inconsistencies, and security concerns. If left unaddressed, this issue could compromise the integrity and reliability of the system.
Proof of Concept
The vulnerability can be demonstrated through the following test scenario:
The provided test scenario confirms that the system behaves inconsistently when the order of addresses in the owner list is changed, leading to the creation of multiple accounts for the same owner.
1 gives 0x761f8B0050e1C64663cdf67b163e139e74f2DDAd::isOwnerAddress;
2 gives0x00b70D9C493558d6F201966236B643EE44a43f30::isOwnerAddress;
when the list of owner was enlogated the system upholds this assertion
Tools Used
The vulnerability was identified through manual testing and analysis, utilizing custom test scripts and the Foundry testing framework.
Recommended Mitigation Steps
The protocol should consider reverting the create wallet function when the number of owners is 2 or should review this function to ensure that the same addresses will not deploy different account with the same nonce
Assessed type
Error