Ethereum Credit Guild - 0xnev's results

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/tokens/ERC20RebaseDistributor.sol#L338-L386

Vulnerability details

Impact

Lack of access control in ERC20RebaseDistributor.distribute() here allows anybody to reset the state variables __rebasingSharePrice and _unmintedRebaseRewards, more specifically, it extends lastTimeStamp and targetTimestamp, effectively reducing the elasped within ERC20RebaseDistributor.interpolatedValue().

A malicious user can front run call to first distribute/subsequent distributes by admin by indefinitely calling distribute with a very small amount of credit tokens (e.g. 1e-18 gUSDC, represented by 1) to reduce linearly interpolated rewards for users. The increase in share price would be so small that there could be no/minimal change to newTargetSharePrice, but the lastTimeStamp and targetTimestamp has already been extended in __rebasingSharePrice and _unmintedRebaseRewards.

This will inturn affect computation of rebasingSharePrice() and unmintedRebaseRewards(), by reducing the interpolation period for the above parameters delta, which in turn reduces rewards of users in spite of them being subscribed to the savings plan for the fixed period of time.

Proof of Concept

The malicious distributor can perform the following scenario:

1. Wait for admin/Lending Term to distribute rewards via distribute(), so existing rebasingSharePrice() is not equal to zero

2. Malicious user can call distribute() with just 1 wei, reducing interpolation period for delta represented by elapsed and targetTimeStamp in interpolatedValue() the computations here due to extension in lastTimestamp and targetTimestamp here and here respectively

Tools Used

Manual Analysis, Foundry

Recommendation

distribute should have relevant access control to only allow an admin to distribute interest earned for rebasing mechanism from lending term or any source at appropriate timings.

Assessed type

Access Control