The Smart Account does not verify the security attestations for the Validator being used during User Operation Execution, which can lead to loss of funds from a compromised Validator.
One of the core principles behind ERC7579 is to be less opinionated about the module permission model while still being reasonably secure by allowing off-chain entities to "attest" to the security of a module in an on-chain registry. These off-chain entities can create and revoke attestation when they see fit. In particular, an attestation may be revoked after being made if a vulnerability is found later.
It is therefore important that in addition to the attestations being verified at the time of module installation, they must also be verified in each transaction when the module is being used. This is also demonstrated in the codebase with the execution module flow, with checks performed at module installation as well as usage.
However, in the case of validation modules, it is observed that while the checks are performed during validator module installation, they are not performed during the execution of the user operation.
Given that Validation Modules are the most commonly used modules, they present a wide attack surface against Smart Accounts. Suppose the security of validation modules is not verified during each execution. In that case, it may lead to a compromised validation module allowing execution of User Operations despite its attestation being revoked. This can lead to a direct loss of funds across all Smart Accounts in which the validator is installed.
Code Inspection.
Given that the registry check requires a non-associated storage read, it is unsafe to call during the validation phase. I assume that this is the reason for skipping this check in the first place. However, it is still possible to verify the attestations during the execution phase, specifically in executeUserOp(PackedUserOperation calldata userOp, bytes32)
. This function has the context of the whole UserOp during the execution phase.
During execution, this function must extract the Validator address from the nonce and verify the attestations by calling the registry. This will ensure that even if a compromised Validator validates a UserOp, it is rejected during the execution phase limiting the damage greatly. The Smart Account / Paymaster would still pay the gas fee for execution of the UserOp, but this should prevent fund loss.
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.