Sablier

Sablier
DeFiFoundry
53,440 USDC
View results
Submission Details
Severity: medium
Invalid

Airstreams generated through contracts such as `SablierV2MerkleLT`, `SablierV2MerkleLL`, and `SablierV2MerkleLockupFactory` can be halted by utilizing ERC20 tokens

Summary

Airstreams generated through contracts such as SablierV2MerkleLT, SablierV2MerkleLL, and SablierV2MerkleLockupFactory can be halted by utilizing ERC20 tokens.

Vulnerability Details

ERC20 assets are accepted without any verification in the SablierV2MerkleLT, SablierV2MerkleLL, and SablierV2MerkleLockupFactory Merkle contracts. No conditions are implemented to validate the ERC20 tokens utilized in these contracts. This loophole provides an opportunity for any malicious actor to introduce their own version of a malicious ERC20 token to exploit the Merkle contracts.

Even after considering the ERC20 assumptions outlined in the protocol's documentation, there remain three avenues through which ERC20 tokens can be utilized to exploit these Merkle contracts:

  1. Pausable ERC20 Tokens: A malicious creator can create a pausable ERC20 token, allowing the admin to halt token transfers at any time for specific or all users. Eg - BNB

  2. Blacklist ERC20 Tokens: Similar to the first scenario, a malicious creator can blacklist specific recipients, preventing them from interacting with the ERC20 contract and transferring tokens. Eg - USDC, USDT

  3. Manipulation of the approve Function: The malicious creator can tamper with the logic of the approve function. Despite providing maximum approval to the Lockup contract, the actual allowance variable will hold a smaller value. This allowance decreases as new streams are created by recipients using the claim function within SablierV2MerkleLT and SablierV2MerkleLL. Eg - DSToken

In the first two scenarios, the malicious actor retains the ability to halt the stream for any recipient at any time. In the last scenario, only the initial recipients can claim their tokens, while subsequent recipients are unable to do so.

Impact

In all the outlined scenarios, the airstream can be halted or made inactive for specific recipients or for all recipients. Airstreams are commonly utilized for airdrops, where projects distribute tokens to a large number of users as a means of introducing and promoting their services. Given that new tokens are frequently employed for airstreams, malicious creators may exploit this vulnerability to target unsuspecting users. Additionally, since recipients can initially create and deploy Lockup contracts to claim tokens, malicious creators can further persuade and deceive recipients into believing in the fairness of their airstream, ultimately exploiting them.

Even after the grace period has elapsed, during which the creator should have no means to halt the airstream, the malicious actor can still pause it or render it inactive for recipients. Subsequently, after the expiration period ends, they can reclaim their tokens by using the clawback function without distributing all the tokens to the recipients as intended.

Furthermore, the malicious actor retains the capability to initiate their attack on any segment of the airstream at their discretion and target any or all recipients, as they have ownership of the token.

Tools Used

Manual Review

Recommendations

Require whitelisting of tokens before allowing any creator to use new tokens. Implement a condition within the constructor of the SablierV2MerkleLockup contract to permit only whitelisted tokens.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Too generic

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.