截至发稿时，这份报告已获得了Curve官方的认可，而作者也因此获得了漏洞奖励，目前Curve正为旧的合约池部署解决方案，而新的合约池不受此漏洞的影响。
以下是漏洞报告内容：在9月19日凌晨的几个小时，我发现了一个针对Curve合约的漏洞，当合约的放大系数A更新时，攻击者可提取大量代币余额。而使用了Curve合约的Swerve，其一度更新了它的A系数，因此用户的潜在损失是巨大的，占到了合约余额的36.9%，假设进行一次优化后的攻击，那么大约会损失9200万美元。幸运的是，Swerve更新顺利通过，没有发生意外情况。那天下午晚些时候，我通知了Curve团队。几个小时后，他们确认了漏洞的存在，我们开始一起研究解决方案。实际上，这种攻击在A向上和向下调整时都可能发生。但是，由于向下调整的潜在损失要大一个数量级，因此我们将重点讨论这类攻击。这些攻击的严重程度与A的变化幅度成正比。事实证明，代币余额份额的最大损失受如下等式的限制，其中A_old是初始参数值，A_new是更新的参数值，而n是合约中代币类型的数量。
利用漏洞造成的损失，取决于参数A的百分比变化例如，yCurve合约的更新，发生在同一周的早些时候。该合约有n=4个代币类型，更新从A_old=2000更改为A_new=1000。使用方程1中的公式，攻击者可利用该漏洞提取高达12.9%的yCurve合约余额。这种攻击只可能在预定的参数A更新过程中进行。Curve合约在正常操作下不易受到攻击，因此，没有必要采取紧急行动来保护用户资金。但是，在发生其它关于A的更改之前修补此漏洞是至关重要的。Curve团队正在对更新A的程序进行改进，这些改进应允许Curve合约以安全的方式继续更新参数A。平均数和代币联合曲线
为了理解攻击，我们有必要了解下代币联合曲线。我将解释一些概念，以便读者能够形成一个概念性的理解。我对这一主题采用了一种稍有不同的方法，重点是代币联合曲线与一组变量平均值之间的关系。在数学中，平均数是表示一组数据集中趋势的量数。因此，如果x_1是n个数集合中最小的数，x_n是最大的数，则这个集合的平均数将呈现为介于x_1和x_n之间的中间值。两种最常见的平均数类型是算术平均数和几何平均数。
算术平均数
几何平均数平均数在代币联合曲线中起到了关键作用。AMM合约允许用户交易任何组合的代币，这样AMM合约代币余额的平均值在交易发生前后保持不变。在不同的AMM设计中，会使用不同类型的平均数方法。对于Uniswap，它使用的是未加权的几何平均数，对于Balancer，它使用的是加权几何平均数，对于mStable，它使用的则是未加权的算术平均数。而Curve使用的是算术平均数和几何平均数的加权平均数，我称之为Curve平均数。Curve平均数的权重由所谓的放大参数A决定。随着A向无穷大方向增加，Curve的平均数收敛到mStable使用的算术平均数。相反，如果A设置为0，Curve的平均数将与Balancer和Uniswap使用的几何平均数相同。对于A的中间值，Curve的代币联合曲线将位于这两个极端的中间。
图1:代币联合曲线图1显示了四种代币联合曲线。Uniswap保持几何平均常数，这产生了一个非常陡峭的曲率。mStable则是算术平均值常量，它是一条直线，而Curve则位于两者之间。在参数值A=1时，Curve类似于Uniswap，在A=10时，Curve更接近于mStable。平均数和AMM合约持有的价值
参考图1，我们可以看到，所有四条曲线在距离图形原点45度线的一个点相交。我们可以利用这个交点到原点的距离，来快速测量AMM合约代币投资组合的价值。例如，如果这个交叉点到原点的距离增加了20%，那么，假设没有无常损失，AMM合约持有的价值也将增加20%。这适用于我们所有的四种联合曲线类型。当我们考虑Curve时，这一特性尤其有用，因为Curve具有一个独特的特性：当A更新时，其联合曲线的形状会发生变化。对于Curve，我们可以使用距离原点的距离来衡量参数更新前后合约投资组合的价值。显然，如果在更新A之后这个距离明显减少，这将是一个严重的问题。关于参数A的盈亏平衡更新
再次参考图1，假设Curve合约的代币余额正好位于45度线的交点处。当所有Curve代币以一比一的价格比率交易时，就会出现这种情况。从这个起点更新A时，就没有货币损失的风险。例如，假设Curve从这一点开始将参数设置A_old=10改为A_new=1。此更新不会更改联合曲线到原点的距离。因此，参数变化将是完全无害的，不会使Curve流动性提供者面临财务损失的风险。直觉上，如果初始余额不完全在交叉点，但接近于这个交点，则损失的风险仍然很小。关于参数A的亏损更新
现在让我们看看图2。该图说明了当更新A时，攻击者如何可能操纵初始条件以实现巨大的利润。为了便于说明，我展示了从A_old=10到A_new=1的变化，而不是Swerve从A_old=1000到A_new=100的更新。然而，事实证明，漏洞的严重程度只取决于新旧比率，因此该数字准确地描述了Swerve的情况。另外，图中所示的攻击只捕获了合约代币库存的15%。而一个完全优化的攻击将交易更极端的金额，从而可捕获多达36.9%的代币库存。
图2：在恶意交易之间增加一个变化假设Curve合约余额最初位于45度线的交点处，且初始参数值为A_old=10。现在假设一个攻击者在两笔恶意交易之间夹了一个参数更新。在第一次恶意交易中，攻击者出售大量代币，以导致库存失衡。接下来，攻击者将触发一个更新，更新的值为10和1。如图所示，这会改变曲线的形状。最后，攻击者以更低的价格买回他出售的代币。此操作将使合约沿45度线返回到完全平衡的状态。如图所示，此次攻击将导致AMM代币库存的15%丢失。利用漏洞的可行性
那这样的攻击真的有可能吗？令人惊讶的是，答案是yes。Curve合约要求提前几天安排A的变更，并通过去中心化的链上治理流程达成共识。但是，一旦通过治理批准了A中的更改，并且超过了激活截止日期，合约允许任何调用方触发更新。因此，攻击者可自由地从Uniswap快速租借大量稳定币，将其出售给Curve以触发极端不平衡，触发对A的更新，然后从Curve购买稳定币以获得巨大的利润。而完全优化的攻击会涉及到更多，这里就不再深入细节。而我上面所描述的简单攻击，就足以捕获大部分潜在利润。修复关于A更改的智能合约逻辑
目前，Curve合约有两个生产版本。对于未修补的旧版合约，上面提到的内容就是漏洞的原理。而对于较新的合约，仍然存在一个潜在的漏洞，尽管其严重性要小的多。我将首先描述旧合约的建议更改。修复旧Curve合约
在旧的Curve合约中，A的变化发生在一个大的离散步骤中。此外，合约逻辑允许攻击者在单笔交易中以不同的A值执行交易。特别是，攻击者可以利用其初始交易来迫使库存极度失衡，然后触发A的变化，然后以更新后的A值执行更多交易。这使攻击者可执行涉及数以亿计资金量交易的整个攻击，而不会涉及到风险。为了解决这个问题，我建议更新旧的合约，以便只有受信任的多重签名帐户才能激活对A的更新。此外，激活A应需要检查代币余额，以确认代币余额从广播参数更新交易的时间点起没有发生显著变化。这种余额检查可防止流氓矿工的攻击。特别是，一个流氓矿工可重新排序交易，这样他在更新A之前执行一笔大交易，然后在A更新后执行另一笔大交易。余额检查可防止在合约处于意外不平衡状态时激活对A的更改，这足以保护CurveLP免受此类攻击。修复新的Curve合约
在较新的Curve合约中，A的变化是在每次交易开始前以一系列离散的小步骤逐渐发生的。我的理解是每一区块只能调整一步。此外，合约要求在执行任何交易之前进行预定的步骤调整。这足以抵御普通攻击者，但不一定能抵御流氓矿工。特别是，一个流氓矿工可以连续铸造两个区块，并在两个区块中插入恶意交易。这将允许矿工在第一个区块中以较高的A值进行初始交易，并在第二个区块中以较低的A值进行最终交易。更糟糕的是，流氓矿工有一个扩展的窗口来尝试这些攻击。只要A还在更新过程中，流氓矿工就可以继续尝试挖取两个区块序列。为了保护这些较新的合约，我建议将A中的步骤长度减小到每个区块不超过0.1%。为什么小的的步骤长度有帮助？这涉及到一个我还没有介绍的因素——Curve合约会收取一笔费用，由于这笔费用，任何交易都会导致代币联合曲线稍微偏离原点。这也适用于攻击者的巨额交易，这使得攻击的利润略有下降。如果A的变化足够小，则完全优化的攻击所获得的收益，将被攻击者支付给合约的费用所抵消。因此，攻击者再也不可能通过在两笔交易之间夹杂一个变化来获利。关于安全审计和智能合约设计的经验教训
关于这种攻击，它要求设计者深入理解代币联合曲线，对于智能合约审计者来说，发现利用高度专业化知识的漏洞可能并不现实。实际上，Curve合约已经过了多次安全审计，在我写这篇文章时，Swerve合约刚刚通过了另一次审计。在我看来，一个通用的，可通过强力探测而不是理论检测的漏洞审计程序，将是非常有用的。为了检测这类漏洞，我建议代币联合曲线审计纳入任意两步交易程序的模拟。在这些过程中，审计人员将针对合约运行一笔随机交易，触发一个智能合约操作，然后运行另一笔随机交易。在此，智能合约操作将激活对A的更新。对于此漏洞，此模糊测试过程将揭示合约遭受灾难性损失的场景。然后，审计人员可以进一步调查，以了解根本原因。对于智能合约设计师来说，了解审计的局限性是有帮助的。当合约允许一次执行一系列复杂的交互时，全面的模糊测试就变得不可行了。问题在于，用户交互的可能组合太多，我们无法探究每一种可能性。因此，限制用户在短时间内可采取操作的数量和种类是很有帮助的。这里的想法是避免创建一个非常复杂的智能合约，以至于无法通过暴力手段进行审计。感谢Curve团队为我的漏洞报告工作支付了一笔非常慷慨的漏洞奖金，另外，特别要提下我在0x的好友GregHysen，是他挖掘了Curve的代码，帮助我理解更新A的智能合约逻辑。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。