Design: 解释安全

你好！

我有一个问题：在这种情况下详细说明以下内容是否有意义：

“除此之外，在源语言级别调用未定义行为的程序可能会被编译成 WebAssembly 程序，这些程序可以执行其他任何操作，包括破坏应用程序堆的内容、使用任意参数调用 API、挂起、捕获或消耗任意数量的资源（在限制范围内）。”
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

我正在考虑的是通过提供示例和进一步讨论来提供可能（可能）用于来自非本地背景的 Web 开发人员的上下文/参考。

例如，CERT 的MSC14-C。 不可移植行为（未指定行为、未定义行为、特定于语言环境的行为、实现定义的行为）并附有示例。 MSC15-CPP。 C 编译器可能会默默地丢弃一些环绕检查，这在这种情况下可能特别值得注意（Robert Seacord 在“Silent Elimination of Bounds Checks”中对此进行了更详细的讨论）。

更深入的治疗：

• 每个 C 程序员都应该了解的关于未定义行为的内容 #1/3
• 每个 C 程序员都应该了解的关于未定义行为的内容 #2/3
• 每个 C 程序员都应该了解的关于未定义行为的知识 #3/3
• C 和 C++ 中未定义行为指南，第 1 部分
• C 和 C++ 中未定义行为指南，第 2 部分
• C 和 C++ 中未定义行为指南，第 3 部分

其他可能相关的建议：

• INT02-CPP。
• INT08-CPP。
• INT10-CPP。
• INT18-C。
• INT32-C。

拥有一个独特的 CSP 头来控制 wasm 文件会有帮助吗？ 我觉得站点所有者可能希望阻止子资源加载 wasm。

这是一个有趣的问题。 绝对我们应该允许站点在他们不允许eval和Function的相同情况下禁止 WebAssembly 的动态加载和评估（这将脱离 ES6 模块集成和对Loader CSP 检查

值得指出 #53 以讨论动态链接的一些安全问题。

@jfbastien 是的， CORS 和 SRI 应该尽可能提供给开发人员。

@lukewagner我想这取决于 wasm 将启用的对资源的低级别访问。 正如您所说的开箱即用，它只是 JS。 然而，wasm 的首要目标似乎是最接近机器金属的东西； 全局控制的 CSP 指令将是一个很好的选择。
随着时间的推移，对其他功能采取更细粒度的方法也会更好。

其他直接的可能性是利用权限 API 进行其他低级别访问。

嗯，在性能上接近金属。 从安全、权限和沙箱的角度来看，没有讨论让 WebAssembly 与 JS 不同。

这不是我从后 MVP 和 Brendan Eichs 公告中得到的感觉，但还好：+1：

我认为你所指的是我们已经同意，在 MVP 之后，WebAssembly 语义将被允许与 JS 中可以有效填充的语义不同。 这种分歧将围绕计算特性，与安全/权限无关。 这意味着，虽然它们不能_有效地_polyfill，但新功能_可以_由用 JS 编写的 WebAssembly 解释器（ Emterpreter 风格）模拟。 最好为此效果添加注释以限制我们所说的“与 JS 的分歧”。

是的，这当然是对文档的一个很好的增强，我可能阅读文档太快了，但它似乎并没有说清楚。

我认为这是 Eichs 关于添加更多线程和内存功能的讨论之一，这让我认为 wasm 会获得新功能。 我怀疑这些很可能也会被添加到 JavaScript 中，并且会受到对新特性的通常审查。

“与安全 POV 与 JS 没有什么不同”现在在Web.md 中。

我宁愿更好地解释这种区别。 从独立的角度来看，引用 JS 并不是很好，我认为我们实际上希望减少 JS 的安全表面区域（例如，跨源脚本等）。

既然我已经在 CppCon 上发表了关于它的演讲，我将开始讨论这个问题:-)

对于那些可能对使用 WebAssembly 作为加密实现目标感兴趣的人，详细说明 JS/asm.js JIT 和 WebAssembly JIT 在支持固定时间实现方面的差异会很有用。 我正在专门考虑诸如位移、后 JIT 引入的分支、条件跳转或查找等操作，或者 JIT 可能进行的其他可能会引入时序泄漏的更改。

如果开发人员不应该期望 WebAssembly 比我们已经拥有的 asm.js 更好地支持固定时间实现，那么说明这将有助于详细说明 WebAssembly 对应用程序设计的安全影响。 如果 WebAssembly 将提供一些方法来更好地强化应用程序而不是当前存在的东西（现在或在 MVP 之后，我还没有深入阅读规范），那也很好详细说明。 https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 有更多关于客户端 JavaScript 加密的现有问题。

顺便说一下，这一切都非常令人兴奋。 :D

同意我们应该按照@dconnolly 的建议进行澄清声明。 到目前为止，我们已经讨论过，对于 MVP，无法保证 JIT 可以/不能做什么，并且恒定时间算法至少对于 MVP 来说不是 wasm 的正确用法。 这在未来可能会改变。

我目前的看法是，外部 API（由嵌入器提供，例如 Web 平台）更适合提供此类保证，因为您经常需要汇编和对微体系结构的良好理解才能编写适当的恒定时间代码。 考虑一个 CPU 进行动态二进制转换的极端例子：WebAssembly 不能保证 CPU 能/不能做什么。 我的观点是 WebAssembly 的抽象级别太高，无法表达真正的常量时间代码。

酷，谢谢你的澄清。 同意 Web 平台 API 是此类事情的最佳场所，尤其是原语（ WebCrypto正在/将支持基本要素，并为未来添加诸如通过注释的新椭圆曲线之类的空间）。 期待关于安全的额外语言，它将帮助任何其他可能误解 WebAssembly 含义的人。 ：+1：

@jfbastien ，你所说的关于 wasm 时间保证的一切今天仍然适用吗？

我在当前的文档中看到，确定性执行是一个目标，除了一小部分记录的边缘情况，这对于恒定时间算法来说听起来可能是积极的。 然而， webassembly.org/docs/security承认定时攻击是可能的，并列出了一些潜在的未来缓解措施，但不清楚这是否意味着“你的错误 C 代码不会被神奇地修复......然而”或“可能会引入典型的 C 编译器不会发生的侧信道漏洞”。

撇开硬性保证不谈，至少了解我们在“恒定时间算法肯定会 100% 被搞砸”和“没有明显的理由不总是期望与 clang 的原生二进制输出相媲美的时序特性”之间的立场是有帮助的。 对于@dconnolly的观点，一些专门将其与 asm.js 进行比较的语言也非常有用——特别是考虑到像 Firefox 这样完全尊重'use asm'语句的实现和像 Chrome 这样的实现有点松散.

@buu700所有操作码的确定性结果并不意味着任何操作码的时间都得到保证。 Clang 也不保证恒定时间执行，如果您正在编写信息泄漏敏感代码，那么恒定时间并不是您所需要的全部。

目前，WebAssembly 没有尝试对信息泄露做出任何保证。

明白了，感谢您澄清关于确定性的部分@jfbastien。

至于时序/侧通道（并忽略保证或缺乏保证），听起来目前规范中没有任何相关内容，也没有关于实际实现与 clang 相比的有用数据？ 在阅读了您之前的评论后，我真正明白的是，在这个领域，wasm 实现是否一定总是比 gcc/clang _更糟_ 是否有一个内在的原因。 您提到抽象级别是一个问题，但不清楚您使用什么作为“足够好”的恒定时序（原生 C、汇编、硬件等）的基线比较。

换句话说，考虑到在 clang 上运行信息泄漏敏感代码和假设的当今 WebAssembly 规范的最佳/最成熟/信息泄漏最坚固的可能实现之间的选择，根据您的理解，前者显然仍是首选？

此时，对于信息泄漏敏感的代码，我既不依赖 clang 也不依赖 WebAssembly。 我目前知道的真正获得我想要的保证的唯一方法是编写程序集，阅读我所针对的特定 CPU 的手册，并与内核密切合作。 如果您真的想独立于时序，知道“x86”或“ARM 64”甚至还不够。

您可以使用某些编译器/语言获得一些保证，但是如果只需要一个信息泄漏来击败您的代码，那么“一些”就不足以保证。

完美，谢谢，我想这回答了我的问题。 同意关于一般信息泄漏威胁建模的所有观点； 我只是想知道 wasm 是否应该被认为比任何其他（无 asm）C 编译目标更容易泄漏，听起来你说的不一定是这样？

我不认为“更漏”是一个有用的措施。 衡量标准是“它到底有没有泄漏？” WebAssembly、clang、C++ 和 C 的答案是“是”。

嗯，具体来说，我想到的是旨在通过纯 C 实现实现某些侧通道电阻特性的算法，例如 @dconnolly 链接的 libsodium/NaCl 示例。 如果某些东西能够在所有可能的攻击场景中幸存下来，这当然是理想的，但了解两件事之间的差异也很有用（即使它们都很糟糕，通过某种程度的糟糕衡量），以及在这种情况下是否使用 WebAssembly 而不是 Linux ABI 作为目标可能会破坏 libsodium 的预期威胁模型。

libsodium 问题线程上的链接评论对库如何与 asm.js 交互提供了非常丰富的信息，但作为一名非专家，我不清楚为 WebAssembly 重写的特定分析听起来像什么（除了 i64 支持和浏览器正在在处理 wasm 方面比 asm.js 更一致）。

但无论如何，我明白你一年前的原点是什么，我真正关心的是你是否做出了比实际更强有力的声明（众所周知，规范会引入特定的新侧信道弱点在标准 C/clang 中找不到，而不是通常都适合该目的），所以感谢您澄清这一点。

>

我不认为“更漏”是一个有用的措施。

@jfbastien ，量化安全是一个与衡量公正有关的领域
那。 常见的度量是有多少位信息被一个
成功的攻击——比如说，1 位和 32 位会产生巨大的差异（并且在
实践几乎每个系统都有微小的潜在泄漏
频道）。 然而，这种量化通常相当困难。

>

我不认为“更漏”是一个有用的措施。

@jfbastien ，量化安全是一个与衡量公正有关的领域
那。 常见的度量是有多少位信息被一个
成功的攻击——比如说，1 位和 32 位会产生巨大的差异（并且在
实践几乎每个系统都有微小的潜在泄漏
频道）。 然而，这种量化通常相当困难。

我知道这一点，并且完全不感兴趣，因为泄漏就是泄漏。 如果它对开发人员很重要，那么它最终会咬我们（WebAssembly 实现者）。 鉴于我们的其他优先事项，我认为 WebAssembly 不应该在短期内尝试解决这个问题，而且 WebCrypto 已经作为一种努力而存在（尽管它可能存在缺点，但解决这个问题比目前的 WebAssembly 更好）。 您当然可以在闲暇时探索这一点。

@jfbastien ，同意这个话题现在没有优先级，那
Wasm 并不比 C 更容易泄漏，而且我们不知道解决的好方法
它。 但是像“泄漏就是泄漏”这样的过度简化在这方面没有帮助
物质——每个系统都有一定程度的泄漏，所以数量实际上就是全部
这很重要。 等待“它咬我们”并不是一种策略
将在真正的潜在受害者中激发很大的信心，即
浏览器用户。

同意...... Wasm 并不比 C 更容易泄漏

很好，感谢您明确确认！ 这就是我来到这里的全部目的：对我应该将其与什么进行比较的一般感觉，而不是保证它是否“不会泄漏”。

@rossberg-chromium 我不认为我会同意 wasm 并不比 C 更容易泄漏的想法。最终这取决于每个引擎如何实现一切。 例如，JavaScriptCore 对代码进行分层，并在可执行内存用完时停止对代码进行分层。 这是 C 代码不存在的泄漏。 我预计，随着 wasm 引擎变得更先进，wasm 可能会像 JVM 一样泄漏。 最终，我不认为规范或实现者可能会努力适应防止信息泄漏，尤其是不以性能为代价。