Closed c4-bot-1 closed 9 months ago
0xRobocop marked the issue as duplicate of #292
0xRobocop marked the issue as sufficient quality report
0xRobocop marked the issue as remove high or low quality report
0xA5DF marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/bd6ee47162368e1999a0a5b8b17b701347cf9a7d/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L394-L403
Vulnerability details
Impact
LiquidInfrastructureERC20.sol
allows the contract owner to block a token holder viadisapproveHolder
. Further, a disapproved holder cannot receive infrastructure tokens. This is enforced in _beforeTokenTransfer. However, this method does not disallow a blocked user to transfer their infrastructure tokens to another holder. The other holder will be collecting the rewards on the behalf of the blocked user. Since the contract owner does not have control over the rewards token (such as USDC), the unblocked holder can simply act as a rewards proxy, perhaps, collecting a fee for doing that.As a result,
disapproveHolder
is a feature that is too easy to circumvent.Proof of Concept
The test
test/poc2.ts
demonstrates that:holder2
may transfer tokens toholder3
,holder3
receives the rewards on behalf ofholder2
,holder3
transfers the rewards back toholder2.
The source code of
test/poc2.ts
:Tools Used
Manual review, Miro, Hardhat.
Recommended Mitigation Steps
One solution is to simply forbid a blocked user to transfer their token to anyone else but to the zero address (that is, burning the locked tokens) in
_beforeTokenTransfer
.Assessed type
Access Control