ZK Email account recovery module enables smart account recovery via decentralized email guardians. It’s ERC-7579 and 4337-compatible, but also usable natively. The recovery process involves adding email addresses as guardians, which can be used to recover accounts if private keys are lost by simply sending an email with the new public key.
ZK Email engaged Ackee Blockchain Security to perform a security review of the ZK Email’sl Email Recovery for a total of 8 engineering days in a period between July 4 and July 12, 2024.
METHODOLOGY
We began our review using static analysis tools, including Wake. We then took a deep dive into the logic of the contracts. For testing and fuzzing, we have involved Wake testing framework. During the review, we paid special attention to:
- checking initialization and configuration processes of recovery modules,
- ensuring proper guardian state management,
- checking event emission consistency and completeness
- checking gas optimization and efficiency in smart contract operations,
- interaction with the ERC-7579 standard,
- detecting possible reentrancies in the code,
- ensuring access controls are not too relaxed or too strict,
- looking for common issues such as data validation.
SCOPE
The audit has been performed on the commit 4e70316
and 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
Here are the findings from our audit.
Critical severity
No critical severity issues were found.
High severity
H1: Multiple vulnerabilities in recovery configuration process
H2: Premature guardian configuration update in addGuardian
function
Medium severity
M1: templateIdx
function parameter check is in incorrect place
M2: Maximum guardians DoS
M3: Selector collisions in UniversalEmailRecoveryModule
M4: MAX + 1 validators may be configured in UniversalEmailRecoveryModule
M5: UniversalRecoveryModule
arbitrary Safe recovery call
Low severity
L1: Validators can be added/removed before module initialization in UniversalEmailRecovery
L2: UniversalEmailRecovery
validators cannot be disallowed after being uninstalled
L3: cancelRecovery
function does not revert when no recovery is in process
Warning severity
W1: isInitialized
function returns false if initialized without guardians
W2: Unused bytes32
function parameter in EmailRecoveryManager
W3: Unnecessary computation of calldataHash
value in validateRecoverySubject
function
W4: Gas inefficiencies in UniversalRecoveryModule
W5: Events missing parameters
W6: Missing AddedGuardian
event emission in setupGuardians
function
W7: ERC-4337 violation in onInstall
Information severity
I1: getTrustedRecoveryManager
function returns public variable emailRecoveryManager
I2: Non-immutable state variables in EmailRecoveryManager
contract
I3: Misleading naming
I4: Unchecked return values in EnumerableGuardianMap
library
I5: Use calldata
in favor of memory
in function parameters
I6: Floating pragma
I7: Missing zero-address validation in constructors
I8: Modifiers not above constructors
I9: Safe validateRecoverySubject
optimization
I10: Unused using-for directive
CONCLUSION
Our review resulted in 27 findings across Revision 1.0 – 1.2, ranging from High to Info severity. The most severe one (H1) originates from the ability to initialize the system without guardians and a zero threshold, which can lead to an invalid configuration and inconsistent guardian state. Another high severity issue (H2) refers to premature update of the guardian configuration in the addGuardian function, which can lead to a situation where the totalWeight value (the sum of weights of guardians) does not accurately reflect the total weight from accepted guardians, potentially making recovery impossible. There are additionally 3 medium severity issues related mainly to the configuration of validators in the modules and support for custom templates. The code also contains multiple low severity issues with warnings/infos, which are mostly overlooked trivial mistakes.
Ackee Blockchain Security recommends ZK Email:
- disallow initialization of the system without guardians and a zero threshold,
- ensure that the system accurately tracks the sum of weights from accepted guardians,
- optimize gas usage of the contracts,
- address all other reported issues.
Ackee Blockchain Security’s full ZK Email audit report, which includes a more detailed description of all findings and recommendations, can be found here.
We were delighted to audit ZK Email and look forward to working with them again.