PA1D: Recipient can grief payouts

[code423n4]

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/24bc4d8dfeb6e4328d2c6291d20553b1d3eff00b/src/enforcer/PA1D.sol#L297

Vulnerability details

Impact

_payoutEth iterates over all recipient addresses and calls transfer on them. Because of that, one single recipient can cause the whole payout to fail (either by reverting in the fallback function or by using too much gas).

Note that the same problem theoretically also exists for _payoutToken, although to a lesser extent, because letting ERC20 transfers revert on purpose is harder as a recipient. However, when ERC777 tokens are used it is possible (with the hook) and for some ERC20 tokens it can also happen without the involvement of the user (e.g., the USDC blacklist). The USDC blacklist could potentially be even used by other persons that are not even a recipient to let all payments fail: When it is possible to get a recipient on the blacklist (e.g., by sending him ETH from Tornado Cash), all USDC payouts will fail.

Proof Of Concept

Let's say one recipient receives a very small share (e.g., 1%) of the payouts and is not happy with that. Therefore, he decides to blackmail the other recipients. He does so by creating a contract that reverts in the fallback function if it is configured to do so. The loss for the individual recipient is very small (1%), but the other 99% of the other recipients are also stuck as long as this contract exists.

Recommended Mitigation Steps

Accumulate the share for each recipient and let them retrieve the ETH, i.e. a pull pattern instead of the current push one (see also https://fravoll.github.io/solidity-patterns/pull_over_push.html for more details).

[gzeoneth]

Duplicate of #33

[gzeoneth]

As QA report