Puffer Protocol: Why Does Access Control Mechanism Matter and How to Improve Its Security

“Puffer is a decentralized native liquid restaking protocol (nLRP) built on Eigenlayer”. It has attracted more than 600 million USD in TVL (Total Value Locked) in just a few days. Access control is an important security consideration to prevent malicious operations on the protocol.

In this blog, we review the entire architecture of the access control mechanism and its current configuration in the Puffer protocol. This can help the community better understand the protocol. Note that the analysis result is based on the current status (Block 19177155, Feb 07, 2024, 03:17:35 PM +UTC) on Ethereum.

Contract addresses

The following table lists the smart contracts used in this blog.

Architecture

The whole protocol mainly includes two smart contracts related to users’ assets. The first one is PufferDepositor, and the second one is PufferVault.

The main functionality of PufferDepositor is to accept users’ assets and then deposit them into PufferVault. If the users' deposit assets are not stETH, the swap into a DEX is automatically performed by the protocol.

PufferVault is the main contract that holds users' assets. It’s also the entry point for deposits into EigenLayer. The main access control of the entire protocol is implemented in this smart contract."

Access Control Mechanism

The whole access control is implemented by leveraging OpenZeppelin’s AccessManager module. The AccessManager smart contract manages the authority of the PufferDepositor and PufferVault contracts.

The AccessManager defines different Roles, which contain different addresses. Each Role can be assigned to invoke different functions inside the AccessManaged contracts (i.e., PufferDepositor and PufferVault). The AccessManager supports the delayed execution of a particular function. That’s when granting a Role to an address, it can specify whether the operations issued from this address in this Role are executed immediately or executed with a time delay.

Current Access Control Configurations

Nevertheless, the effectiveness of the access control depends on its configuration. We have observed numerous instances where a flawed configuration of ACL (Access Control List) rules has led to security vulnerabilities.

To address this, we have reviewed the current configuration of the Puffer protocol and present the results below. Please note that these results only reflect the status as of Block 19177155 (Feb 07, 2024, 03:17:35 PM +UTC).

Roles

Below is a table outlining the current roles within the system and their associated addresses.

There are different execution paths to execute functions inside the PufferValut contract. One path involves the TimeLock contract (with the ADMIN Role – as shown in Path 1 in the figure), and the other path allows direct invocation of functions inside the Vault, with the role assigned to the caller. In both cases, the invocation must go through the AccessManager.

Type I: Invocation from TimeLock Contract

Note that when invoking a function from the TimeLock contract, the assigned Role is ADMIN. This designation arises because, from the Vault's perspective, the caller is the TimeLock contract, which possesses the ADMIN Role. Consequently, the TimeLock contract incorporates an additional layer of delayed execution mechanism.

• Operation SafeWallet: This component can invoke functions within the target contract after a delay of 604,800 seconds (approximately 7 days).
• Community SafeWallet: This component has the capability to immediately invoke functions within the target contract. It also possesses the authority to cancel any pending execution in the queue submitted by the Operation SafeWallet.
• Pausing SafeWallet: This component is restricted to pausing the target contract and is not authorized to execute any other functions.

Type II: Direct Invocation of the Vault Contract

The subsequent method involves directly invoking functions within the Vault contract. It's important to note that the AccessManager dictates which functions can be invoked by the addresses associated with each Role.

Both the Operation and Community SafeWallets have the capability to directly invoke the upgradeToAndCall function to upgrade the target contract. The key distinction lies in the timing: the Community SafeWallet executes this action without any delay, whereas the Operation SafeWallet is subject to a delay.

Moreover, the Operation SafeWallet is equipped to immediately execute functions that transfer assets into EigenLayer and initiate withdrawal requests.

Updated on [Feb-08-2024 10:02:59 AM +UTC]

An operation aiming to remove the Operation SafeWallet from Role 1 has been scheduled. This operation is slated for execution after block 1707940908, which corresponds to an estimated delay of approximately 7 days. The simulation of these queued transactions was conducted using Phalcon Block.

• The simulated transaction in Phalcon Fork to execute the queued execution on 2024-02-18 17:59:07 (UTC), ten days later.
• The simulated transaction to query whether the Operation SafeWallet still has Role 1 (return false)

See all transactions in this Fork.

Updated on [Feb-16-2024 20:10:23 AM +UTC]:

• The transaction to remove the Operation SafeWallet from Role 1 has been executed. We can check the result from Etherscan.

Safe Wallet Configurations

The configuration of a safe wallet also affects the protocol’s security.

Updated on [Feb-08-2024 10:02:59 AM +UTC]:

• The address 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 has been removed from the Operation SafeWallet, adjusting its authorization to 3/5.
• A transaction to remove 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 from the Community SafeWallet has been initiated and is currently awaiting multisig approval from the community.
• Three wallets have been removed from the Pausing SafeWallet, now adjusting its configuration to 1/9.

Summary

In this blog post, we have reviewed the security mechanisms utilized by the Puffer protocol. Overall, the design of the entire permission system is comprehensive.

The community should actively monitor for potential risks:

• The security of the private keys of the Community SafeWallet owners is paramount. If three private keys are compromised, it could allow an attacker to upgrade the vault.
• The security of dependent protocols, such as EigenLayer, should also be actively monitored.