BCH 升级攻击事件安全分析

攻击导致了矿工节点无法打包，BCH 方面通过类似于空块攻击的方式，紧急挖出十个空块以触发滚动检查点保证升级。攻击发生约 1 小时后，BCH 矿池上线紧急修复后的代码成功继续出块。

不过同时也有人观察到，在 582698 区块高度，有矿工挖出了哈希结尾为 6bf418af 的区块，大小 139369 字节。但随后该区块被 10 分钟后 BTC.top 挖出的哈希结尾为 449e2bb4 区块所重组。或许是一次误伤，不过可见 BCH 对于升级防守之严密。

攻击原理分析

4c83ab55623633c86ec711b3d68ccdea506b228178ff1533f287ab744b006c44

其内容点击 附件 查看。

该攻击载荷由 1334 个 Input 构成，每一个 Input 均是 P2SH 格式。

其内容为

该攻击载荷利用了一个 CORE 曾经帮 ABC 修复，但未完全修复的漏洞，制造了组块和验证之间的差异，从而导致矿工组出的区块不被节点接受。

漏洞背景

相关代码位置： src/consensus/consensus.h#L27

static const uint64_t MAX_TX_SIGOPS_COUNT = 20000;

漏洞原理

相关代码位置： src/validation.cpp#L1936

if (nSigOpsCount > nMaxSigOpsCount) {
    return state.DoS(100, error("ConnectBlock(): too many sigops"),
                     REJECT_INVALID, "bad-blk-sigops");
}

补丁位置： https://reviews.bitcoinabc.org/D3053

相关代码位置： src/validation.cpp#L592

// 原代码
int64_t nSigOpsCount = GetTransactionSigOpCount(tx, view, STANDARD_SCRIPT_VERIFY_FLAGS);
// 补丁代码
int64_t nSigOpsCount = GetTransactionSigOpCount(tx, view, STANDARD_CHECKDATASIG_VERIFY_FLAGS);

可见原代码组块过程中在计算 Transaction 中的 SigOP 数量时，错误地使用了 STANDARD_SCRIPT_VERIFY_FLAGS，而非 STANDARD_CHECKDATASIG_VERIFY_FLAGS。

这两个标志有什么区别呢？

在 policy 中我们可以找到他们。

相关代码位置： src/policy/policy.h#L108

static const uint32_t STANDARD_CHECKDATASIG_VERIFY_FLAGS =
    STANDARD_SCRIPT_VERIFY_FLAGS | SCRIPT_ENABLE_CHECKDATASIG;

因此，攻击载荷会在矿工组块的时候被包含进区块中，然而，由于其他代码正确地统计了 SigOP，节点会拒绝该区块，这导致了 BCH 无法出块。

总结

攻击者利用了 BCH 引入 OP_CHECKDATASIG 时产生的，又未完全修复的漏洞，巧妙地构造了攻击载荷。攻击者应该高度了解客户端代码，并熟悉 OP_CHECKDATASIG 漏洞。

来源：慢雾科技