dss-auto-line griefing attack
The current implementation of the dss-auto-line contains a potential griefing vulnerability.
The essential function of the auto-line is to allow public users to increase or decrease a collateral
line value by some amount
gap, which results in a new
line value that is the existing debt balance plus the
gap. The line will not increase if the last increase happened less than
ttl seconds ago. The line will decrease regardless of how many seconds have elapsed since the last change.
The motivation for adding the delay between increases is to mitigate the risk that the price of a collateral is read higher than the current market price.
In the worst case, the oracle price is higher than market price by more than the collateralization ratio buffer, which would allow one to fill a Vault and generate the maximum amount of Dai against the collateral, thus causing the Vault to be under 100% CR in the next oracle update. If the
ttl is too short, anyone could increase the
line multiple times before the oracle price matches the market price, which would cause the protocol to take on excess amounts of bad debt. Mitigating against this risk is the reason we have debt ceilings in the first place, and also the reason the
ttl should not be too short.
Decreasing the debt ceiling carries no such risk, and is in fact desirable if the oracle price for an asset is considerably higher than the market price. For this reason, there is no
ttl before decreasing the debt. It’s this lack of a
ttl before decreasing the debt that creates the potential for a griefing attack.
This griefing attack would allow a user with a large vault to prevent the
line from increasing after the
ttl. There could be a financial incentive to perform this attack in a Dai liquidity crunch, which would allow the vaultholder to corner the Dai market and prevent supply over a critical period. While the protocol has, and will create more, Vaults that are available in a liquidity crunch, it’s still worth considering this attack vector for an asset.
Hypothetical scenario is as follows
- auto-line is configured with a
gap of 5,000,000 and a
ttl of 1 hour.
- malicious vaultholder has $10,000,000 (or more) worth of collateral in
WBTC-A and 5,000,000 Dai in debt.
WBTC-A line is 160,000,000,
WBTC-A total debt is 160,000,000
- malicious vaultholder calls
AutoLine.exec("WBTC-A") which increases
line to 165,000,000
- malicious vaultholder flash borrows 5,000,000 Dai and repays all or a portion of their debt. Total debt is now 155,000,000
- malicious vaultholder immediately calls
AutoLine.exec("WBTC-A") which decreases
line to starting value of 160,000,000
- malicious vaultholder generates 5,000,000 Dai and repays flash loan
line value remains at 160,000,000 for the next hour
- legitimate vaultholder is unable to generate more Dai for the remaining
- This problem is compounded if malicious vaultholder repeats the attack hourly.
- A shorter
ttl would make this attack more operationally expensive, but it also reduces the effectiveness against oracle attacks.
- A larger
gap would require an actor with more resources, however this sort of assumption might not work in a world of flash loans.
ttl for DC decreases. This would prevent us from being able to cap the DC to
gap if the market price was lower than the oracle price, and doesn’t prevent the griefing attack, it just pushes it to the end of the new
- We’ve removed the ability for flash loans to be used to execute this attack here.
The smart contracts domain team as limited the griefing attack to actors with extremely large positions. We believe this reduces the risk of griefing the debt ceiling significantly, enough that the other benefits of this module may be realized. Nevertheless, we suggest deploying this with just ETH-B for now. This allows domain teams and governance to get used to the functionality of the module, and if the griefing attack proves to be a problem, ETH-A is always available for additional debt.
Some future notes about when we consider this module for other collateral types.
- By removing the flash loan capability in conjunction with this module, it would mean an attacker would have to have the capital to fill the
gap in order to execute a griefing attack. Under the mitigation section, we discussed making the
gap larger in order to make this attack less available.
- Make sure certain collateral types like USDC-B, or perhaps those managed by any future implementation of a PSM are not managed by this module.
NOTE: While we think the risk is low, it would still be helpful if the community could think about various motivations for this attack, other than those mentioned above. What would an attacker gain by griefing one, many, or all, of the collaterals that use this module?
@brianmcmichael for the initial discovery and writeup of this attack.
@Primoz et al. for discovering this independently in a risk review. Great work!
@galabasquer implementing the DC IAM, and the flash loan mitigation.