如果被利用，这些漏洞可能允许攻击者未经授权访问敏感信息或通常会导致问题
几天前我Wasmtime 6.0.1、5.0.1 和 4.0.1 修正更新发布 该 他们可以修复漏洞 （已编入 CVE-2023-26489 目录）被评为严重。
脆弱性 允许在允许限制之外的内存区域中组织数据写入 对于隔离的 WebAssembly 代码，攻击者可能会使用它来在隔离的 WASI 环境之外编排代码的执行。
对于那些不熟悉 Wasmtime 的人，您应该知道这是一个用于运行带有 WASI（WebAssembly 系统接口）扩展的 WebAssembly 应用程序作为普通独立应用程序的运行时。
Wasmtime 是用 Rust 编写的，并且 该漏洞是由于路由规则定义中的逻辑错误造成的 Cranelift 代码生成器中的线性内存，它将独立于硬件架构的中间表示转换为 x86_64 架构的可执行机器代码。
关于修复的漏洞，特别提到， 计算出有效的 35 位地址 对于 WebAssembly 应用程序 而不是 WebAssembly 中允许的 33 位地址，这将允许读写操作的虚拟内存限制更改为 34 GB，而沙箱环境设置为 6 GB 提供了保护。 从基地址。
Wasmtime 的代码生成器 Cranelift 在 x86_64 目标中存在错误，地址模式计算会错误地计算出 35 位有效地址，而不是 WebAssembly 定义的 33 位有效地址。 这个错误意味着，使用默认代码生成配置，wasm 控制的加载/存储操作可以读取/写入距离线性内存基址最多 35 位的地址。
结果是， 从基地址开始的 6 到 34 GB 的虚拟内存范围可用于读写 来自 WebAssembly 应用程序。 该内存可以容纳其他 WebAssembly 环境或 WebAssembly 运行时组件。
例如(i32.load (i32.shl (local.get 0) (i32.const 3)))，是从WebAssembly地址$local0 << 3加载的。翻译成Cranelift时，$local0 << 3的计算为一个 32 位值，被零扩展为 64 位值，然后添加到线性存储器的基地址。 Cranelift 会生成一个形式为 movl(%base, %local0, 8), %dst 的语句，计算 %base + %local0 << 3。
然而，这里的错误是地址计算发生在 64 位值上，其中 $local0 << 3 应该将地址截断为 32 位值。 这意味着可以使用最多 0 位地址的 %local32 获得了额外的 3 位地址空间，可以通过 movl 访问。
最后， 一如既往，建议将软件包更新到可用的最新版本还值得一提的是，如果无法更新，可以使用多种可能的解决方案来缓解此问题。
提到这些解决方案都不是默认打开的，需要显式配置：
- 如果无法更新 Wasmtime 的版本，则会提到选项“Config::static_memory_maximum_size(0)”以启用对任何线性内存访问的强制性单独边界检查作为阻止错误的解决方法（导致性能显着下降） ).
- 另一种选择是使用“Config::static_memory_guard_size(1 < 36)”设置来增加位于有问题的虚拟内存范围内的保护页（Guard Page，访问时抛出异常）的数量（导致保留大量的虚拟内存）内存并限制并发 WebAssembly 应用程序的数量）。
- 如果可以使用非 x86_64 主机，也可以修复此错误。 例如，此错误不会影响 Wasmtime 或 Cranelift 的 AArch64 后端。
最后 如果您有兴趣了解更多信息， 您可以在中查看详细信息 以下链接。