Fjord Token Staking

Summary

Protocol heavily uses Solmate's SafeTransferLib in the `FjordStaking.sol`.

Now, there is a subtle difference between the implementation of solady (solmate’s) SafeTransferLib and OZ’s SafeERC20:

• OZ’s SafeERC20 checks if the token is a contract or not.

• solady’s SafeTransferLib does not. (it's based on solmate safetransferlib) See here: https://github.com/Vectorized/solady/blob/main/src/utils/SafeTransferLib.sol#L10

Note that none of the functions in this library check that a token has code at all! That responsibility is delegated to the caller. As a result, when the token’s address has no code, the transaction will just succeed with no error. This attack vector was made well-known by the qBridge hack back in Jan 2022, you can check here: https://www.halborn.com/blog/post/explained-the-qubit-hack-january-2022.

Vulnerability Details

It’s becoming popular for protocols to deploy their token across multiple networks and when they do so, a common practice is to deploy the token contract from the same deployer address and with the same nonce so that the token address can be the same for all the networks.

A sophisticated attacker can exploit it by taking advantage of that and setting traps on multiple potential tokens to create fake deposits. For example: 1INCH is using the same token address for both Ethereum and BSC; Gelato's $GEL token is using the same token address for Ethereum, Fantom and Polygon. Also, attacker can frontrun one new token deployment and create fake deposits before it hit the chain, so this attack vector can be exploited via deposits.

Impact

Medium, considering there is a list of whitelisted tokens; however, this should be considered if more tokens are ever going to be integrated.

Tools Used

Manual Review

Recommendations

Verify if the token has code before integrating.