Submitted by Aamir, also found by 0rpse, 0x0dd, 0xrex, gesha17, ilchovski, KupiaSec, and spuriousdragon
LiquidProxy.sol#L39
The Ron staking contract let us earn rewards by delegating our tokens to a validator. But you will only earn rewards on the lowest balance of the day (source). So if you delegate your tokens on the first day, you are going to earn 0 rewards for that day as your lowest balance was 0 on that day. This will happens with every new delegator.
Now the issue with LiquidRon is that, there will be many users who will be depositing their tokens in it. And there is no such kind of time or amount restriction for new delegators if some people have already delegated before them. So with direct delegation, the new rewards flow will be this:
But if we deposit through LiquidRon it has become this:
Now a user can earn rewards by just depositing the tokens into the LiquidRon by frontrunning the new rewards arrival and immediately withdraw them. But if a user try to do this by frontrunning the LiquidRon::harvest(...) call, this will not be possible. Because when he deposits, he will get shares in return which will already be accounting for any unclaimed rewards through getTotalRewards(...) in LiqiuidRon::totalAssets(...):
But instead of frontrunning this harvest(...) call, a user can just frontrun the new rewards arrival in the RonStaking contract itself. Because as per the Ronin staking docs, a user will be able to claim new rewards after every 24 hours.
Also, if we look at the _getReward(...) (used by claimRewards etc.) function of the Ronin staking contract, the rewards will be same as before as long as we are not in new period: 
Github: Link
So if a user frontrun before this, the getTotalRewards(...) function will also not account for new rewards as long as we are not in new period.
Also note that, if a user frontruns and deposit, he didnt not actually delegated his tokens as the tokens are only delegated once the operator calls LiquidRon::delegateAmount(...) function:
So a user is just depositing, claiming and withdrawing his tokens but not actually delegating.
The following attack can be summarized like this:
In the above case, the user didnt have to stake his tokens and still earns the share of the rewards. Also, this can be done each and every time to claim the rewards.
He also didnt have to bear any risk of loss in case something bad happens (maybe some kind of attack) and the share price value goes down; while others will also have to bear this loss.
Incorporate some kind of locking mechanism for new depositor like Ron staking contract does. Or, go for some alternate option.
Owl (Liquid Ron) confirmed and commented:
0xsomeone (judge) commented:
Liquid Ron mitigated:
Status: Mitigation confirmed. Full details in report from Aamir.
