Merge pull request #236 from euler-xyz/update-cs-findings

update preliminary findings from ChainSecurity

audits/ChainSecurity_preliminary_findings.txt

@@ -6,7 +6,21 @@ THIS IS WORK IN PROGRESS
 For example:
 If the violator has 85 units of collateral with 0.8 LTV and 80 units of debt. A liquidator can liquidate the position all at once with a discount factor of 0.85. The liquidator will receive 72.25 units of debt and 85 units of collateral thus making 12.75 in the process. The violator's position will end up with 7.75 (bad) debt. However, the liquidator can decide to perform the liquidation in two steps, liquidating half of the position first and then the other half. The liquidator will end up with 36.125 + 34 debt and 42.5 + 42.5 collateral, resulting in a profit of 14.875. The violator's position will at the end contain 9.875 debt which is more debt than if the liquidation would have been performed at once. The difference was earned by the liquidator.
 
-Comment from Euler: See https://github.com/euler-xyz/euler-vault-kit/pull/191
+Preliminary response from Euler:
+
+We have made a set of 3 changes to the liquidation system in order to mitigate the issues discovered by our auditors.
+The first issue raised is related to the "Counterproductive Incentives" issue described by OpenZeppelin in their [2019 Compound audit](https://blog.openzeppelin.com/compound-audit). Liquidation systems that incentivise liquidators with extra collateral value as a bonus (or discount) can, in some circumstances, leave violators *more* unhealthy than they were pre-liquidation. In the Euler system, the discount is proportional to how unhealthy the user is, which means that in these cases, a liquidator may improve their total yield by performing many small liquidations, rather than one large liquidation. Each smaller liquidation will decrease the user's health and therefore increase their discount for subsequent liquidations, up until the maximum liquidation discount is reached. As described in our [Dutch Liquidation Analysis](https://docs.euler.finance/Dutch_Liquidation_Analysis.pdf) research paper, this scenario can be avoided by selecting an appropriately low maximum discount factor.
+Change 1: With this in mind, we have added EVK functionality that allows governors to configure the vault's maximum discount factor. In many cases, governors will compute an appropriate maximum discount based on the highest configured LTV for the vault, although there may be other considerations involved. A governor must specify a value for this parameter, otherwise the liquidation system will not function properly.
+The second issue raised is a general observation that price manipulation can be used to attack lending markets, and that some of the oracles we would like to support have special challenges. In particular, pull-based oracles like Pyth and Redstone provide more flexibility to attackers because they can typically choose to use any published prices within an N-minute window. For example, an attacker may be monitoring prices off-chain, waiting for a large decline in the price of a vault's collateral asset (or, equivalently, a large increase in the price of the liability asset). If the decline is sufficiently large, the attacker will search the previous N-minutes of prices and select the pair with the largest difference. The attacker will then submit a transaction that performs the following attack:
+* Updates the oracle with the old price
+* Deposits collateral and borrows as much as possible
+* Updates the oracle with the new price, causing the position to become very unhealthy
+* Liquidates the position from another separate account, leaving bad debt. This bad debt corresponds to profit from the attack at the expense of the vault's depositors
+Although impossible to solve in the general case, to reduce the impact of this issue we have have made two modifications to the EVK:
+Change 2: We now allow the governor to configure separate borrowing and liquidation LTVs. This requires the attacker to find correspondingly larger price jumps.
+Change 3: We have added a "cool-off period" where an account cannot be liquidated. Cool-off periods begin once an account has successfully passed an account status check, and last a governor-configurable number of seconds. By setting a non-zero cool-off period, accounts cannot be liquidated inside a block that they were previously healthy.
+The consequence of this is that the attack described above can no longer be done in an entirely risk-free manner. The position needs to be setup in one block but liquidated in a following block, potentially opening up the opportunity for other unrelated parties to perform the liquidation instead of the attacker. Additionally, such attacks cannot be financed with flash loans. As well as price-oracle related attacks, this protection may also reduce the impact of future unknown protocol attacks.
+More generally, the cool-off period allows a vault creator to express a minimum-expected liveness period for a particular chain. If the maximum possible censorship time can be estimated, the cool-off period can be configured larger than this, with the trade-off being that legitimate liquidations of new positions may be delayed by this period of time.
 
 2. In Governance.sol we noted that if convertFees has not been called in a while and then the protocolFee is modified that the new fee distribution between the governor and the protocol will be applied retroactively to the unclaimed fees.