kiki_dev - malicious or paused tokens can cause claiming to fail.

[github-actions]

kiki_dev

high

malicious or paused tokens can cause claiming to fail.

Summary

Atomic Bounty is meant to be a way for users to claim a varitey of assets. And depositFunds allows anyone to deposit either a whitelisted token a whitelisted NFT or a non-whitelisted token. the issue here is that a user can create a custom token that reverts whenever it is transfered to an address that is not that bounty. Or whenever the bad actor is not one of either the _to or _from. For example erc-777 tokens have before and after trnasfer hooks. A bad actor can add logic to the before trnasfer hook that would cause the transfer to fail.

This is bad for this protocol becasue atomic bounty is claimed in a loop. And one bad token can cause the entire claim to fail making it impossible for a claimant to recieve the rewards from the bounty that they earned.

Vulnerability Detail

Here is a scneario:

Alice creates a atomic bounty and she supplies 1000 $Gods and 1 eth
A bad actor submits a his own token $HALT
Bob completes the bounty and tries to claim
In the claim function it first attempts to transfer the $GODS, all goes well
Then it attempts to transer the 1 eth, all goes well
Then it tries to transfer $HALT
Bob being the bad actor that he is, he put special logic into the beforeTransfer hook that immedialty reverts.
Becasue this transfer reverted all previouse work in this transaction is undone.
The bounty is now unclaimable.

This can happen when there is one token or 100 as long as a malicouse token is allowed to be in the loop a bad actor can always make claiming impossible.

Note: token doesnt even have to be mailicous a paused token can do the same thing.

Impact

unusable protocol
Loss of compensation for claimant

Code Snippet

https://github.com/sherlock-audit/2023-02-openq/blob/main/contracts/ClaimManager/Implementations/ClaimManagerV1.sol#L133

Tool used

Manual Review

Recommendation

There should be a way to remove malicious tokens from atomic queue. This could even be an option that is limited to claimant. Where if a transaction fails they can see what token caused it and choose to remove it from the reward queue.

Duplicate of #62