Sablier

Summary

Malicious users can create linear/dynamic/tranched streams without paying broker fee in some tokens.

Vulnerability Details

When protocol create linear/dynamic/tranched streams internally call Helpers#checkAndCalculateBrokerFee function:

As we can see, the protocol firstly calculate brokerFee based on totalAmount and brokerFee, then subtract the brokerFee from totalAmount and calculate the deposit amount, it use ud(totalAmount).mul(brokerFee) to calculate the brokerFee amount, which is a function from prb library.

After test, it's possible that ud(totalAmount).mul(brokerFee) would become 0 if totalAmount * brokerFee less than 1, then solidity round down the result to 0, such that brokerFee would be 0 and broker will not receive any broker fee.

From contests compatibilities description and dapp site we can know, the protocol support any standard ERC20 token and also deployed on polygon. When underlying token‘s
decimal is small like 2, such as polygon EURO token decimal is 2, the malicious users can batch create streams with small amounts without paying broker fee.

note: EIP-20 don't specify token decimals must be 18, it could be 2, 6 and 8.

We use polygon euro token as an example:

Execute git patch to patch the diff directly.

Result:

As we can see, when polygon EURO token as underlying token with totalAmount = 333, broker = 0.3%, 333 * 0.003 = 0.999 then round down to 0 by solidity, malicious users can create 250 times LockupLinear streams in one tx without paying broker fee, the gas cost is 28843555 less then polygon block limit 30,000,000, the free created stream tokens value is 832$ euro.

Impact

Malicious users can create linear/dynamic/tranched streams with small amounts without paying broker fee if underlying tokens decimal is small.

Tools Used

vscode, Manual Review

Recommendations

Calculate the amounts.deposit by totalAmount * (1 - brokerFee) first, then calculate the amounts.brokerFee by totalAmount - amounts.deposit to make sure the amounts.brokerFee never become 0. This issue is similar to the-graph-rounding-error-bug, so the mitigation can be same.