Metamask Delegation Framework

Description

The NativeTokenPaymentEnforcer is an enforcer that, combined with a delegation D1, ensures a delegate pays to redeem D1. The delegate that redeems the delegation D1 must include in the arguments of this enforcer a delegation D2 to the NativeTokenPaymentEnforcer itself. It will give the right to the enforcer to pull the amount specified in the first place in the terms of the NativeTokenPaymentEnforcer to exercise the delegation D1.

To prevent front-running and the use of the second delegation D2 by a malicious actor who inspects the mempool, the usage of the ArgsEqualityCheckEnforcer enforcer is recommended with terms being the delegationHash of the first delegation D1. This will ensure that the delegation that is being paid for with the delegation D2 is the delegation D1. While this works well when the delegation D1 is restricted to a specific delegate, it is not sufficient in the case of open delegations.

The Delegator framework offers the possibility to create an open delegation. The purpose of an open delegation is that it can be redeemed by anyone.

The problem is that the computed delegationHash, is based on the fields of the delegation structure and the enforcers terms. However, in case of an open delegation, the delegate field will contain the same value (ANY_DELEGATE) regardless of who is currently redeeming the delegation.

The DelegationManager contract will accept the redeem from anyone when the delegation delegate field is ANY_DELEGATE.

src/DelegationManager.sol:L154

if (delegations_[0].delegate != msg.sender && delegations_[0].delegate != ANY_DELEGATE) {

In such a scenario, anyone using D1 would share the same delegationHash in the arguments. Consequently, someone could watch the mempool and front-run a legitimate redeem by leveraging the delegation D2. The attacker would be able to execute his own action with the delegation D1 but use the delegation D2 (which was generated by someone else) to pay the right to exercise it.

Recommendation

Ensure that the consumer of the delegation D2 (also known as immediate delegator) is the current redeemer of the delegation D1. This could be done using the redeemer parameter of the afterHook function of the NativeTokenPaymentEnforcer enforcer.

Description

In NativeTokenPaymentEnforcer, the redeemer must include a payment delegation to pay the delegator to execute an execution. The payment delegation can be created by the redeemer or some other contract or account in behave of the redeemer(e.g. redeemer’s smart account). However, this setup introduces a vulnerability where another redeemer can front-run the original redeemer by capturing and utilizing the same payment delegation specified in the _args parameter of the afterHook function in the NativeTokenPaymentEnforcer. In such cases, the payment would still be covered by the original redeemer or its root delegator.

To prevent front-running, it is recommended to use the ArgsEqualityCheckEnforcer to ensure that the redemption can only be executed by the original redeemer and the delegation is not open (delegate != ANY_DELEGATE), this is done by validating the delegation hash (_delegationHash), which is derived from the redeemed delegation. However the use of ArgsEqualityCheckEnforcer is currently optional within the payment delegation, not mandatory. Furthermore, even it’s enforced, the vulnerability remains when the delegation is open (issue 3.1) . In this scenario, the _delegationHash would be identical for any redeemer, which fails to prevent front-running effectively.

Examples

src/enforcers/NativeTokenPaymentEnforcer.sol:L78-L102

Delegation[] memory delegations_ = abi.decode(_args, (Delegation[]));

// Assign the delegation hash as the args to the args equality enforcer.
for (uint256 x = 0; x < delegations_.length; ++x) {
    Delegation memory delegation_ = delegations_[x];
    for (uint256 i = 0; i < delegation_.caveats.length; ++i) {
        if (delegation_.caveats[i].enforcer == argsEqualityCheckEnforcer) {
            delegation_.caveats[i].args = abi.encodePacked(_delegationHash);
        }
    }
}

bytes[] memory permissionContexts_ = new bytes[](1);
permissionContexts_[0] = abi.encode(delegations_);

bytes[] memory executionCallDatas_ = new bytes[](1);
executionCallDatas_[0] = ExecutionLib.encodeSingle(recipient_, amount_, hex"");

ModeCode[] memory encodedModes_ = new ModeCode[](1);
encodedModes_[0] = ModeLib.encodeSimpleSingle();

uint256 balanceBefore_ = recipient_.balance;

// Attempt to redeem the delegation and make the payment
delegationManager.redeemDelegations(permissionContexts_, encodedModes_, executionCallDatas_);

Recommendation

In function afterHook add a require statement to check whether the immediate delegator (delegation_[0].delegator) of the payment delegation is equal to the redeemer (_redeemer ).

Description

The standard ERC-7579 outlines the minimal required interfaces and behavior for modular smart accounts to ensure interoperability across implementations. However, It should be noted that this ERC is currently in draft status and may be prone to changes until it reaches the final version.

The current Delegator implementation contains discrepancies with the ERC-7579 draft. Here is a list of identified discrepancies:

• the account must implement the account config interface which is composed of the following functions:

  • accountId(): helps to identify the current account;
  • supportsExecutionMode(): helps to determine which execution mode is supported;
  • supportsModule(): helps to know which module is supported.

• the account must implement the module config interface which is composed of the following functions:

  • installModule(): installs a new module;
  • uninstallModule(): uninstalls a module;
  • isModuleInstalled: helps to know if a module is installed.

• Each component must implement the module interface which is composed of the following functions:

  • onInstall(): callback executed by the smart contract account on installation;
  • onUninstall(): callback executed by the smart contract account on uninstallation;
  • isModuleType(): helps to determine the type of the current module;

• The standard separate modules into the different types:

  • Validation (type: 1): The signature validation function implemented in HybridDeleGator and MultiSigDelegator must be in modules of Validation type;
  • Execution (type: 2): DelegateManagercontract must be registered as a module of type Execution because it is the contract that can execute transactions on behalf of the smart account via a callback.
  • Fallback (type: 3);
  • Hooks (type: 4): Enforcers contracts must be registered as modules of type hooks.

• The hooks in ERC-7579 standard are the equivalent of enforcers in the Delegator’s codebase. To comply with the naming convention of the standard, the functions must be respectively changed from beforeHook and afterHook to preCheck and postCheck

Recommendation

Modify the current architecture and/or implement the missing features to comply with the ERC-7579 standard. However, as the standard is in draft status, it may change until its final version.

Description

The NativeTokenPaymentEnforcer is an enforcer that, combined with a delegation, ensures a delegate pays to redeem it. This enforcer relies on a second delegation that gives the right (to the NativeTokenPaymentEnforcer enforcer) to pull the necessary amount to pay to exercise the first delegation. This is done through another call to the redeemDelegation with a specifically crafted executionCallData that will call the recipient sending the funds.

src/enforcers/NativeTokenPaymentEnforcer.sol:L94

executionCallDatas_[0] = ExecutionLib.encodeSingle(recipient_, amount_, hex"");

When this inner delegation is redeemed, a callback to the recipient is performed. During this callback, the recipient gains execution control flow and can perform arbitrary calls that can change the final state of the transaction.

It is to be kept in mind that this callback could contradict the restrictions put in place with the enforcers of the first delegation but after the executions of the afterHook of these ones.

Recommendation

A strong warning should be mentioned for the NativeTokenPaymentEnforcer enforcer that the payment gives potential code execution to the recipient and that it could completely change the final state of the transaction.