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.