Sablier

Vulnerability Details

Description

In the provided smart contract, a malicious recipient can prevent the cancellation of a stream by the sender through a frontrunning attack. This is possible due to the sequence of checks and state updates in the cancel and _cancel functions. Specifically, the vulnerability arises from the fact that an attacker can deplete the stream by withdrawing the remaining funds just before the sender's cancellation transaction is processed. If the stream is found to be depleted, the cancel function will revert, thus preventing the sender from canceling the stream and reclaiming the remaining funds.

• Scenario

1. The stream has remaining funds that can be withdrawn by the recipient.

2. The stream is cancelable by the sender.

3. The attacker can monitor and detect pending transactions in the memepool

4. The attacker submits a withdrawal transaction with a higher gas fee to ensure it is mined before the sender's cancellation transaction.

Affected Functions

• cancel(uint256 streamId)

• _cancel(uint256 streamId)

Reversion Points

• if (_streams[streamId].isDepleted) { revert Errors.SablierV2Lockup_StreamDepleted(streamId); }

• if (streamedAmount >= amounts.deposited) { revert Errors.SablierV2Lockup_StreamSettled(streamId); }

Proof of Concept

1. Setup: Assume there is a stream with ID streamId and remaining funds that the recipient has not yet withdrawn.

2. Monitor: The attacker monitors the memepool for pending transactions involving the cancel function call for streamId.

3. Frontrunning: When a cancel transaction is detected, the attacker submits a withdraw transaction to claim the remaining funds. This transaction is sent with a higher gas price to ensure it is mined before the cancel transaction.

4. Execution: The withdraw transaction is processed first, depleting the stream.

5. Reversion: When the cancel transaction is subsequently mined, it reverts due to the stream being depleted.

6. MoreClaiming: Sender wanted to cancel the stream and withdraw remaining funds but malicious recipient always attempts withdraw before cancelling to withdraw all the remaining funds that sender doesn't want to stream

Recommended Mitigation

• Atomic Operations

Combine the withdrawal and cancellation processes into a single atomic operation to ensure that no funds can be withdrawn once the cancellation process starts.

• Time Locks and Delay Mechanisms

Introduce time locks or delay mechanisms to allow a buffer period before executing critical operations like cancellation. This would give legitimate users time to react to potential attacks.