同一函数重入漏洞的检测

Question

我正在阅读http://pages.cpsc.ucalgary.ca/~joel.reardon/blockchain/readings/ndss2018_09-1_Kalra_paper.pdf中讨论的宙斯工具对相同功能重入性的检测。他们已经做了克隆。我不明白这个方法。这是一种测试智能契约( SC )的有效方法，因为我们正在修改SC吗？我们可以在测试期间修改SC吗？

报纸上说：

实体中的可重入性可以通过调用方法来实现。为了日志记录的目的，发送仅使用有限的gas调用默认函数。ZEUS首先克隆考虑中的函数，然后在调用之前插入对克隆的调用，从而处理相同的函数重入性。图14示出了图2中示例的修补函数。注意，宙斯确保补丁在相同的基本块内完成，以确保如果调用克隆函数，则调用也进行。此外，我们还在调用代码之前断言false。如果验证器找到指向此断言的路径，则表示存在错误。

谁能帮我理解一下

Answer 1

在这种情况下，他们会验证正确性，作者将其定义为

遵守安全的方案拟订做法

他们有效地测试的是重入漏洞的根本原因:不尊重检查-效果-交互模式。

以它们的示例代码为例：

function withdrawBalance() {
    uint amountToWithdraw = userBalances[msg.sender];

    // CHECK
    if (amountToWithdraw > 0) {
        // INTERACTION
        withdrawBalance’();
        msg.sender.call(userBalances[msg.sender]);
        // EFFECT
        userBalances[msg.sender] = 0;
    }
}

它不尊重范式，这里是检查-交互-效果。这意味着恶意攻击者可能通过实现再次调用withdrawBalance的回退函数从自身调用withdrawBalance。

因此，调用堆栈将是：

• WithdrawBalance
• 回退函数
• WithdrawBalance

执行两次withdrawBalance，因此在应该禁止的地方撤回两次。他们的克隆方法人为地创造了一条可能允许重入攻击的路径。

如果验证器找到指向此断言的路径，则表示存在错误。

事实上，如果可以利用这条道路，我们的例子中就存在双重退出等漏洞。如果正确的编程实践得到尊重，这条路径就不应该被利用。

现在，以这个稍微修改过的示例为例，与以前一样，但只需要尊重CHECK - EFFECT交互模式：

function withdrawBalance() {
    uint amountToWithdraw = userBalances[msg.sender];

    // CHECK
    if (amountToWithdraw > 0) {
        // EFFECT
         userBalances[msg.sender] = 0;
        // INTERACTION
        withdrawBalance’();
        msg.sender.call(userBalances[msg.sender]);
    }
}

再次，我们对克隆函数进行了包含的调用，但是它创建的路径是不可利用的，因为在交互步骤之前应用了“效果”(if (amountToWithdraw > 0))，因此rentrency攻击不会通过检查步骤( userBalances[msg.sender] = 0;)。

这是一种测试智能契约( SC )的有效方法，因为我们正在修改SC吗？我们可以在测试期间修改SC吗？

你可以亲眼看到它在那些例子中是有效的。它确实稍微修改了原来的函数流，并增加了一个气体小开销，但它允许显式检测相同的函数可重入漏洞，这是预期的目标。

只要您的测试不改变智能契约的逻辑或任何不变式，它就会非常好。这种克隆方法不会改变其中的任何一个(至少在本例中是这样)。

有些例子表明，这种方法不起作用，并且无意中干扰了智能契约逻辑/不变量，在使用X gas调用类似的函数时，期望在退出函数或还原之前留下Y气体，它们检测方法的气体开销会破坏您的合同逻辑。

然而，这将是一个不好的做法，因为你不应该假设操作码气体成本是恒定的时间。但这表明，这种克隆方法虽然大部分是正确的，但并不总是正确的。