-
Notifications
You must be signed in to change notification settings - Fork 9
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
Attacker can gain control of counterfactual wallet #460
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
H-03
primary issue
Highest quality submission among a set of duplicates
satisfactory
satisfies C4 submission criteria; eligible for awards
selected for report
This submission will be included/highlighted in the audit report
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Comments
code423n4
added
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
labels
Jan 9, 2023
gzeon-c4 marked the issue as primary issue |
c4-judge
added
the
primary issue
Highest quality submission among a set of duplicates
label
Jan 17, 2023
This was referenced Jan 17, 2023
Closed
#278 also described a way to make the user tx not revert by self destructing with another call. i.e.
|
This was referenced Jan 17, 2023
Closed
This was referenced Jan 17, 2023
livingrockrises marked the issue as sponsor confirmed |
c4-sponsor
added
the
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
label
Jan 26, 2023
gzeon-c4 marked the issue as satisfactory |
c4-judge
added
the
satisfactory
satisfies C4 submission criteria; eligible for awards
label
Feb 10, 2023
gzeon-c4 marked the issue as selected for report |
c4-judge
added
the
selected for report
This submission will be included/highlighted in the audit report
label
Feb 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
H-03
primary issue
Highest quality submission among a set of duplicates
satisfactory
satisfies C4 submission criteria; eligible for awards
selected for report
This submission will be included/highlighted in the audit report
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccountFactory.sol#L33-L45
Vulnerability details
A counterfactual wallet can be used by pre-generating its address using the
SmartAccountFactory.getAddressForCounterfactualWallet
function. This address can then be securely used (for example, sending funds to this address) knowing in advance that the user will later be able to deploy it at the same address to gain control.However, an attacker can deploy the counterfactual wallet on behalf of the owner and use an arbitrary entrypoint:
https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccountFactory.sol#L33-L45
As the entrypoint address doesn't take any role in the address generation (it isn't part of the salt or the init hash), then the attacker is able to use any arbitrary entrypoint while keeping the address the same as the pre-generated address.
Impact
After the attacker has deployed the wallet with its own entrypoint, this contract can be used to execute any arbitrary call or code (using
delegatecall
) using theexecFromEntryPoint
function:https://github.com/code-423n4/2023-01-biconomy/blob/main/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L489-L492
This means the attacker has total control over the wallet, it can be used to steal any pre-existing funds in the wallet, change the owner, etc.
PoC
In the following test, the attacker deploys the counterfactual wallet using the
StealEntryPoint
contract as the entrypoint, which is then used to steal any funds present in the wallet.Recommendation
This may need further discussion, but an easy fix would be to include the entrypoint as part of the salt. Note that the entrypoint used to generate the address must be kept the same and be used during the deployment of the counterfactual wallet.
The text was updated successfully, but these errors were encountered: