Does this mean that MIP27 can’t be deployed until a new implementation is developed to work around this problem? Where do we go from here?
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
gapof 5,000,000 and a
ttlof 1 hour.
- malicious vaultholder has $10,000,000 (or more) worth of collateral in
WBTC-Aand 5,000,000 Dai in debt.
WBTC-Aline is 160,000,000,
WBTC-Atotal debt is 160,000,000
- malicious vaultholder calls
- 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
lineto starting value of 160,000,000
- malicious vaultholder generates 5,000,000 Dai and repays flash loan
linevalue 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
ttlwould make this attack more operationally expensive, but it also reduces the effectiveness against oracle attacks.
- A larger
gapwould require an actor with more resources, however this sort of assumption might not work in a world of flash loans.
ttlfor DC decreases. This would prevent us from being able to cap the DC to
gapif 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
gapin order to execute a griefing attack. Under the mitigation section, we discussed making the
gaplarger 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?
@brianmcmakerdao 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.
If I understand correctly,
At the end of the day, once the flash loan risk is removed, we currently have a same risk. If I recall it has already happen with USDC or ETH when we had 0%. someone filled up the vault to push governance to increase then remove the loan.
Except that with the MIP27 it is 5h instead of one week.
The other option, but I guess you have already thought about it and there is an issue somewhere that I can’t see.
We save the previous line and allow people to go back to it with out ttl. If it is with in the previous ttl.
Good stuff Mooney! Took me a bit to fully understand it–I have read about griefing on Minecraft and insufficient gas griefing, but never about a main dish of collateral shortfall/DC disruption/griefing with a side dish of Flash Loans haha
Hey @yaronvel wanted to circle you into this thread and ask if you can help the community think of any other attacks that would motivate a malicious vaultholder to increase
line with other collateral types outside of ETH, such as WBTC-A and perhaps the proposed/talked about WBTC-B collateral type? Your thoughts would be helpful!
I am not sure i fully understand, but wouldn’t an attacker without extra capital would be able to perform same attack simply by temporarily decreasing his position?
E.g., I withdraw the DAI to supply liquidity to uniswap, and now I use the ETH/DAI LP as a collateral to borrow more dai, and then i repay some of my DAI debt.
Or I withdraw DAI to supply liquidity to curvfi, and now i use it as a collateral at cream to borrow DAI.
Or even simpler, just take my current ETH collateral to a minimum, put it in another vault, and mint DAI.
But more generally why only capital-less (aka flash-loan) attack is the issue?
It seems only whales could apply it anw, so assuming they have few millions on the side, on alternatively that they could decrease their debt by few millions using their extra collateral, is not unlikely.
In WBTC-A (and other mintable coins, like USDC), one motivation to increase
line is when the admin key is being compromised (in WBTC it is technically more than just admin key, but same idea), and infinite minting occur. The more DAI one could mint wrt the now 0 value WBTC, the more profitable your attack was.
Even in the absence malicious intents, i think it is always the interest of WBTC (but also YFI etc) whales to increase the
line, so their coins would have more usage, and they could e.g., mint DAI to get some yield on it in curvfi or pickle.
For the proposed WBTC-B, the backstop has an incentive to have biggest
line as possible, as over time it will bring more users. But this is solvable by setting the absolute cap to a reasonable value.
4 posts were split to a new topic: ETH-B DC-IAM: Initial Parameters
Oh, if it wasn’t clear from my original post, a whale can still grief the DC. This is why I wanted the community to think of strong reasons to do so, and if it’s obvious this would become a problem from whales.
Removing the ability for anyone to grief the DC, we believe, lowers the risk of this happening to a point where the protocol can benefit from a more automated DC. That is, the risks outweigh the benefits. To test this out, we suggested just putting it on
ETH-B to start, as the automated increases would prove useful, and if a whale did grief the DC,
ETH-A still exists as an escape hatch.
Also it states that the fix only mitigates a flash loan. but it seems that you have to be a whale to begin with ($5m net position) to execute the attack. So it is not really about flash loan right?
That said, personally I don’t see a way where one can directly profit from it.
It’s possible that in a Dai squeeze a whale could attempt to corner the market on Dai, driving up the price the price of Dai and profiting from that while retaining the exclusive ability to create it. That said, with the initial proposal to use this only on ETH-B I’m not entirely sure that this is undesirable from a system security perspective. Since ETH-B has the lowest collateralization ratio this “attack” could protect the system by encouraging the use of other vault types with higher collateralization ratios and fees (like USDC-B), increasing the overall system collateralization in a market downturn.
Is this fixable just by adding a cooldown for any changes? Adding the flash-loan guard gives one block for others to interrupt the cycle. What if you just have a 1 hour delay that triggers after any change (up or down) in addition to the 12 hour ttl on increases?
That way you can reduce the debt ceiling rapidly during downturns, but you wouldn’t be able to decrease the ceiling until 1 hour after you increased it.
yeah, so reducing the supply or just an attack by a competitor that want more people to borrow DAI on his platform.
But hard to put $ value to it.
That said, other than simplicity, what other advantages are there in making the
line going down quickly, as opposed to the
line increasing which is more gradual?
Is it to always to put a tight upper bound on the profits from an oracle attack?
We’d discussed this, but the shorter delay provides mitigation against oracle attacks in a rapid market downturn or against an oracle attack, by quickly lowering the collateral line we put an upper limit the ability of users to print unbacked Dai before the OSM update.
I think we want to limit DC exposure to rapid price crashes where the delta of market price is much lower than the oracle price. This can happen with an oracle attack or otherwise (BT). Having no
ttl on lowering is a huge advantage in this case. It remains to be seen if this advantage outweighs the possibility a whale griefs the DC-IAM.
This was one of the backup plans. It still means the grief can happen after that cooldown period, but would create a window where the DC could not be lowered. This window, however, needs to be shorter than OSM updates to limit DC exposure in a crash. If we see this grief attack being a problem in the future, this is the lowest hanging fruit for a solution, but we loose some of the security functionality of capping the ceiling.
Human-managed updates of the collateral
line could be regarded as having a large
gap of often 10-50% of the previous
ttl on the order of weeks. A sufficiently well financed “attacker” could perform a similar griefing attack on the current non-automated, human-managed system. As soon as the
line is set through an executive, the attacker could mint sufficient DAI to reach the
line, blocking other vaults from minting. The attacker could even continue to mint more DAI to compensate for other vaults paying down their DAI debt to keep the total DAI minted at
line. This situation could be maintained until a few days before the community is to decide to raise the
line, at which point the attacker would pay back the DAI and disappear. Suddenly, the community will note DAI generation is far below the debt ceiling and may keep the
line unchanged or maybe even lower it.
So maybe the dss-auto-line griefing attack is not so severe given that the current-human managed
line is also theoretically vulnerable to a similar attack.
I am bringing up this MIP, to check if anyone has an idea about a fix to mitigate this issue?
I can’t see where the git repo is for this MIPs.
Any idea where I can clone the repo?
Edit : Ok found it.
It is actually different as the line can’t go down. Or at least an external user can increase and decrease the line, only governance can do it.