Platform: Code4rena
Start Date: 05/05/2022
Pot Size: $125,000 DAI
Total HM: 17
Participants: 62
Period: 14 days
Judge: leastwood
Total Solo HM: 15
Id: 120
League: ETH
Rank: 7/62
Findings: 1
Award: $6,389.44
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: dirk_y
https://github.com/code-423n4/2022-05-alchemix/blob/main/contracts-full/AlchemistV2.sol#L676-L683 https://github.com/code-423n4/2022-05-alchemix/blob/main/contracts-full/AlchemistV2.sol#L704 https://github.com/code-423n4/2022-05-alchemix/blob/main/contracts-full/libraries/Limiters.sol#L84
In the AlchemistV2
contract, users can deposit collateral to then borrow/mint the synthetic tokens offered by the protocol. The protocol also defines a minting limit that specifies how many synthetic tokens can be minted in a given time period. This exists to prevent unbounded minting of synthetic tokens.
Every time a user calls mint
, the internal _mint
method decreases the current mint limit. This works as intended. However, there is nothing stopping an attacker from immediately burning their synthetic tokens by calling burn
and then calling mint
again. This is possible because the debt position is updated during the burn
phase, which lets the user then mint again against the same deposited collateral.
In most cases this probably wouldn't be a problem if the mint limit is sufficiently high. However, it is currently possible for a well financed attacker to grief the contract by repeatedly minting and burning synthetic tokens to keep the contract pegged at the mint limit. This will prevent any normal users from minting any synthetic tokens, and hence prevents the protocol from performing as it should.
An attacker can repeatedly call mint
followed by burn
after depositing some collateral with deposit
. If this is appropriately sized and timed, it can cause the mint
call to fail for another user due to the check here that is called during mint
here.
VSCode
There should be an additional method added to the Limiters
library that can increment the mint limit. This method can then be called during a burn
call in the AlchemistV2
contract.
function increase(LinearGrowthLimiter storage self, uint256 amount) internal { uint256 value = self.get(); self.lastValue = value + amount > self.maximum ? self.maximum : value + amount; }
#0 - 0xfoobar
2022-05-23T00:58:51Z
Sponsor disputed
If somebody griefed, let alone the insanely high capital requirements, governance could simply raise the mint limit.
#1 - 0xleastwood
2022-06-06T09:10:31Z
As far as I can tell, this seems like a valid griefing attack. Assuming no fees are charged on mint/burn actions, it would be viable to use a flash loan to use up the entire mint limit, preventing other users from participating in the protocol. This could be mostly mitigated by charging a small fee on mints, which is sent to the protocol's governance contract or distributed to pre-existing stakers. Could you confirm this @0xfoobar ?
#2 - 0xfoobar
2022-06-06T22:20:41Z
Upon further review the griefing action of
would be a valid approach to grief the protocol. No funds are at risk but we'll discuss internally how to best mitigate this.
#3 - 0xleastwood
2022-06-08T12:34:33Z
Agreed, keeping this issue as is!
#4 - 0xleastwood
2022-06-08T14:01:22Z
To follow up on this too, this could have been upgraded to high risk if the ease of attack involved:
But as the issue raised does not lead to a loss of user's funds, I believe medium risk to be justified.