ZK Email Account Recovery module enables smart account recovery through decentralized email guardians. Compatible with ERC-7579 and 4337, but can also be used natively. The recovery process involves adding your email address as a guardian, which can be used to recover your account if you lose your private key by simply sending an email with your new public key.
ZK Email In collaboration with Ackee Blockchain Security, we conducted a security review of email recovery from ZK Email for a total of 8 engineering days from July 4 to July 12, 2024.
methodology
We began our review using static analysis tools, including: awake. We then took a closer look at the logic of the contract. Used Wake testing framework for testing and fuzzing. During the review process, we paid special attention to the following:
- Check the initialization and configuration process of the recovery module,
- Ensure appropriate care of caregiver status,
- Check event emission consistency and completeness
- Ensure gas optimization and efficiency of smart contract operations;
- interaction with ERC-7579 standard,
- Detect possible reentrancy in your code,
- Ensure access controls are neither too relaxed nor too strict
- I’m looking for common problems like data validation.
range
An audit has been performed on the commit. 4e70316 The exact scope was the following files:
- ./EmailRecoveryManager.sol
- ./modules/EmailRecoveryModule.sol
- ./modules/UniversalEmailRecoveryModule.sol
- ./handlers/EmailRecoverySubjectHandler.sol
- ./libraries/EnumerableGuardianMap.sol
- ./libraries/GuardianUtils.sol
- ./handlers/SafeRecoverySubjectHandler.sol
- ./factories/EmailRecoveryFactory.sol
- ./factories/EmailRecoveryUniversalFactory.sol
Findings
The audit results are as follows:
critical severity
No critical severity issues were found.
Severity High
H1: Multiple vulnerabilities in the recovery configuration process
H2: Update early caregiver composition addGuardian function
medium severity
M1: templateIdx The function parameter resolution is in the wrong place.
M2: Maximum Guardian DoS
M3: Selector conflict UniversalEmailRecoveryModule
M4: You can configure up to + 1 validator. UniversalEmailRecoveryModule
M5: UniversalRecoveryModule Random safe recovery calls
low severity
L1: Validators can be added/removed before module initialization. UniversalEmailRecovery
L2: UniversalEmailRecovery Once removed, a validator cannot be rejected.
L3: cancelRecovery Functionality is not reverted when recovery is not in progress.
warning severity
W1: isInitialized If initialized without a guardian, the function returns false.
W2: Not used bytes32 function parameters EmailRecoveryManager
W3: Unnecessary calculations calldataHash give value validateRecoverySubject function
W4: Gas inefficiency UniversalRecoveryModule
W5: Event with missing parameter
W6: missing AddedGuardian event emission setupGuardians function
W7: ERC-4337 violation onInstall
Information Severity
I1: getTrustedRecoveryManager The function returns a public variable. emailRecoveryManager
I2: immutable state variable EmailRecoveryManager contract
I3: Misleading naming
I4: Unchecked return value EnumerableGuardianMap library
I5: Enabled calldata approval memory In function parameters
I6: Floating Pragma
I7: Missing zero address validation in constructor.
I8: No modifier above constructor
I9: Safety validateRecoverySubject Optimization
I10: Unused using-for directive
conclusion
Our review resulted in 27 findings ranging from High to Informational severity across revisions 1.0 – 1.2. The most serious issue (H1) arises from the ability to initialize the system without a guardian and a zero threshold, which can lead to misconfigurations and inconsistent guardian states. Another high severity issue (H2) refers to premature updating of the guardian configuration in the addGuardian function. This can lead to situations where the totalWeight value (the sum of the guardian weights) does not accurately reflect the total weight of the allowed guardians. It makes recovery impossible. Additionally, there are three medium severity issues related to the module’s validator configuration and custom template support. The code also contains several lower severity issues with warnings/information, which are mostly minor mistakes that are overlooked.
Ackee Blockchain Security recommends ZK email.
- Do not allow system wipes without a guardian and with a threshold of 0.
- Make sure the system accurately tracks the weighted totals of approved guardians.
- Optimize the gas usage of your contract,
- Addresses all other reported issues.
You can find Ackee Blockchain Security’s full ZK Email Audit report, which includes a detailed description of all findings and recommendations. here.
We are delighted to have appreciated ZK Email and look forward to working together again.