Closed code423n4 closed 1 year ago
gzeon-c4 marked the issue as duplicate of #460
If you recommend to add entryPoint to the salt then handler should also be added to the salt.
Additional notes: If the owner address is changed it doesn't affect the user as only that specific owner will be the controller of the smart account. If for a counterfactual wallet entry point initialised is different than intended, then the owner can update the entry point on their own smart account to a right one. But I agree this should be evaluated..
livingrockrises marked the issue as disagree with severity
livingrockrises marked the issue as sponsor confirmed
agree with severity as per proof shown in issues like #460 but lack of proof here
livingrockrises requested judge review
gzeon-c4 marked the issue as partial-50
gzeon-c4 marked the issue as satisfactory
gzeon-c4 changed the severity to 3 (High Risk)
Lines of code
https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccountFactory.sol#L33 https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L166
Vulnerability details
Impact
Detailed description of the impact of this finding.
Proof of Concept
The entrypoint is being set in the
init(args...)
function of SmartAccount.sol. The problem is that the malicious users could create wallets for legitimate owners of wallets and set the entrypoint contract to be anything they want.What's more, a wallet creation for a user could be frontran by a malicious actor, returning exactly the same address as expected, but with a different entry point. The reason is that the entryPoint is not being used as the salt.
Recommended Mitigation Steps
Add entrypoint to salt.