【硬核文章】Dfinity前工程师教你如何审查IC Canister

互联网计算机系统提供遵循actor模型的容器间通信：容器间调用通过两个异步消息实现，一个用于发起调用，另一个用于返回响应。容器是以原子方式处理消息（并在某些错误情况下回滚），但不完成调用。使得使用容器间调用的编程容易出错。 而出现错误、漏洞或简单的意外行为可能是以下原因造成的：

• 在发起容器间调用之前读取全局状态，并假设它在调用返回时仍然保持读取；
  

• 在发起容器间调用之前更改全局状态，并在响应处理程序中再次更改它，但假设没有任何其他状况更改其之间的状态（重入攻击）；

• 在发起容器间调用之前更改全局状态，并且没有正确处理故障，例如当处理回调的代码回滚时；

如果在你的代码中发现了这样的模式，你应该分析恶意方是否可以触发它们，并评估影响的严重性。

这些问题适用于所有容器，但这并不是 Motoko 特有的。

由于以下原因（可能不完整），与恶意容器交互可能存在风险：

• 另一个容器可以拒绝响应。虽然互联网计算机的双向消息通信规范旨在保证最终响应，但是只要对方愿意在响应之前付费，就可以进行忙循环。更糟糕的是，此外还有很多方法可以使容器宕机；

• 另一个容器可以用无效编码的Candid 进行响应。这将导致 Motoko 实现的容器陷入回复处理程序，从而无法轻松恢复。其他CDK可能会提供更好的方法来处理无效的 Candid，但即便如此，仍必须担心Candid Cycles炸弹会导致回复处理程序陷入困境。

许多容器甚至可以不进行容器间调用，只调用其他可信赖的容器即可。（这是一个需要评估的可选项）。

无论出于何种原因，在 canister_preupgrade 系统方法中陷入困境的容器都不可再升级。 这是一个重大风险。

Motoko 容器的 canister_preupgrade 方法由任意系统 func preupgrade() 块中编写的代码组成。然后系统生成的代码将任意稳定变量内容序列化为二进制格式，并复制到稳定内存。

• 映射容器（可能是链下），并在升级后手动再水合化；

• 在每次更新调用期间，使用ExperimentalStableMemoryAPI手动存储在稳定内存中，虽然这与高保证 Rust 容器（例如 Internet Identity）所做的相匹配，但这需要对数据进行手动二进制编码，并且标记为实验性的，因此Dfinity前工程师（Joachim Breitner）目前不建议这样做；

• 在 Motoko 有稳定变量的可扩展解决方案之前，不要放入 Motoko 器（例如，将它们永久保存在稳定内存中，在主内存中使用智能缓存，从而消除对预升级代码的需求）。

容器在升级期间应该保留所有实时数据。Motoko 会自动确保这一点以获得稳定的变量数据。但是容器通常希望以不同的格式处理他们的数据（例如，在未共享的对象中，不能放入稳定的变量中，例如 HashMap 或 Buffer 对象），因此需要遵循以下习惯用法：

在这种情况下，更重要的是检查：

• 所有不稳定的全局变量，或具有可变值的全局变量，都有一个稳定的伴侣；

• 不会遗忘foo和foostable的赋值；

• 以fooToStable和fooFromStable形式双射。

一个示例是通过Iter.toArray(....entries()) 和HashMap.fromIter(....vals()) 存储为数组的HashMap。

值得指出的是，代码视图只会查看代码的单个版本，而无法检查代码更改是否会保留升级时的数据。如果以不兼容的方式更改稳定变量的名称和类型，这很容易出错。在这种情况下升级可能会失败，在糟糕的情况下，升级甚至也可能会成功，但是会在此过程中丢失数据。这种风险需要通过彻底的测试和备份来减轻（见下文）。

由于上述提到在容器升级时可能会面临到的风险，Dfinity前工程师（Joachim Breitner）的建议是采用恢复策略，以便可以重新安装（而不是升级）容器并重新上传所有数据。此过程可能涉及所有相关数据的链下（或其他备份方案）备份。

如果进行大数据负载测试（Dfinity前工程师Joachim Breitner推荐测试可升级性），这样可以测试备份查询方法是否在资源限制内有效。

互联网计算机提供给容器“当前时间”的时间戳保证是单调的，但不是严格单调的。即使在相同的消息中，只要它们在同一个块中处理，它就可以返回相同的值。因此，它不应该用于检测“发生在之前”的关系。

此问题的另一个解决方案是引入一个var v : Nat计数器，在每个更新方法和在每次等待之后使用该计数器。现在V是容器状态计数器，可以在很多方面像时间戳一样使用。

当我们谈论时间时：系统时间（通常）在等待期间发生变化。因此，如果你确实让 now = Time.now() 然后等待，那么 now 中的值可能不再是你想要的。

由于IC的“容器付费”模式，所有容器都容易通过耗尽其周期余额而遭受DoS攻击，在开发时需要考虑这种风险。

最基本的缓解策略是监控容器的Cycles平衡并使其远离（可配置的）冻结阈值。

在原始 IC-level，可能有进一步的缓解策略：

• 如果所有更新调用都经过身份验证（请尽快执行此身份验证），可能在解码调用者的参数之前。这样，未经身份验证的攻击者进行的Cycles消耗攻击就不太有效（但仍有可能）;

• 此外，实现 canister_inspect_message 系统方法允许在消息在被互联网计算机接受之前执行上述检查。但它不能防御容器之间的消息，因此不是一个完整的解决方案； 

• 如果来自经过身份验证的用户（例如利益相关者）的攻击，则上述方法无效，有效的防御可能需要涉及的额外程序逻辑（例如每个调用者的统计信息）来检测此类攻击，并做出反应（例如限速）；

• 但是只有一种方法是不适用的（例如未经身份验证的用户注册方法），则此类防御毫无意义。如果应用程序天生就可以通过这种方式攻击，那么为其他方法提高防御是不值得的。

Motoko实现的容器目前无法执行大多数这些防御：参数解码会无条件地发生在任何可能基于调用者拒绝消息的用户代码之前，并且不支持 canister_inspect_message。此外，Candid 解码不是很防御Cycles，并且应该假设可以构造需要许多指令来解码的 Candid 消息，即使对于“简单”参数类型签名也是如此。

Dfinity前工程师（Joachim Breitner）此次审计容器的结论是依靠监控来保持Cycles平衡，即使在攻击期间，如果可以承担费用，也许会启动IC-level DoS保护。

如果公共方法允许不受信任的用户发送永久保存在容器内存中的无限大小数据，则存在另一个 DoS 攻击向量。由于将 async-await 代码转换为多个消息处理程序，这不仅适用于存储在全局状态中的数据，还适用于跨越等待点的本地数据。

此类攻击的有效性会受到互联网计算机的消息大小限制（大约为几兆字节），但其中的许多消息也会叠加。

如果方法具有允许 Candid 空间炸弹的参数类型，则问题会变得更糟：这意味着可以在 Candid中编码非常大的向量，所有值都为 null，因此如果任何方法具有 [Null] 或 [?t] 类型的参数，一个小消息会在 Motoko 堆中扩展为一个大值。

其他需要注意的类型：

Nat 和 Int：这是一个无界自然数，因此可以任意大。然而，Motoko 表示不会比 Candid 编码大多少（因此这不符合空间炸弹的要求）。

Principal：Principal实际上是一个 Blob。在接口规范里Principal的长度最多为 29 个字节，但 Motoko Candid 解码器当前是不会检查的（在 Motoko 的下一个版本中修复）。在此之前，作为参数传递的 Principal 可能很大（msg.caller 中的Principal是系统提供的，因此是安全的）。如果你不能等待修复程序到达手中，请在等待之前手动检查princpal的大小（通过 Principal.toBlob）。