2026/11/6

OpenEXR 修复 EXR 文件读取中的 15 个漏洞

软件

OpenEXR 库的开发者于 10 月 31 日发布了补丁版本 3.5.3。该版本修复了 15 个漏洞，其中 10 个仍在等待分配 CVE 编号。几乎所有漏洞都在读取损坏或特意构造的 EXR 文件时触发：包括缓冲区溢出和越出已分配内存的写入。据该版本的作者所述，其中若干缺陷可被用于远程执行代码。

对工作室而言，这是一个实实在在的风险。EXR 序列来自外包方、客户、他人的素材库和文件分享服务，而打开它们通常不会经过单独的检查。攻击要生效并不需要运行该文件：只要基于存在漏洞的 OpenEXR 版本的程序尝试读取它就够了。同一天，在 3.5.3 之前不久，面向上一分支的 3.4.17 版本发布。它修复了其中涉及 3.4 分支的九个漏洞，因此 3.4 的用户可以直接升级，而无需转到 3.5。

问题出在哪里

修复清单涵盖了 EXR 进入内存的几乎所有路径：

DWAA/DWAB 压缩：五项，包括解码器中的越界内存写入、压缩数据流过短时未初始化数据的泄露，以及在通道经过二次采样时访问空指针；
B44 压缩：计算解压块大小时的溢出，作者明确将其标注为可导致远程代码执行，以及编码器在二次采样时的缺陷；
deep 图像：解压以 ZSTD 压缩的 deep 数据时的两个缺陷，以及重新保存分块（tiled）deep 文件时的溢出。据开发者判断，后者可能是旧缺陷修复不彻底所致；
HTJ2K：解码时的错误内存访问；
多部分（multipart）文件：没有大小限制的文件头可能使程序以平方级的时间和资源开销去解析它；
OpenEXR 的 Python 模块：两个 RGB 通道组名称相同时的缓冲区溢出，以及在过时的通道读取接口中按攻击者选定的偏移量进行写入；
文件头属性：通道名称长度超过 31 字节时访问已释放的内存，以及由于未经校验的附加通道列表而导致的溢出。

开发者明确与远程代码执行相关联的那个缺陷，在发布说明中是这样描述的：

“由于计算 B44 块解压大小时的整数溢出而导致的堆越界写入 —— OpenEXRCore 中的远程代码执行”。

3.5.3 中没有新功能，也没有其他行为变更，只有对 deep 图像回归问题的修复（详见下文）。用户还可能注意到另一点：该库现在对输入数据的检查更为严格，会拒绝不正确的文件。在能够捕捉内存操作错误、未定义行为和线程竞争的调试检查下，整套测试现在可以无错通过。完整的变更清单位于 CHANGES.md 文件中。

此次发布还包含什么

在大端（big-endian）系统上读取 deep 图像。自 3.4.14 版本起，由于字节序方面的缺陷，该库在此类机器上会得到错误的采样数量表。小端系统不受此影响。该修复同样包含在 3.4.17 中。
支持 Python 3.15，面向使用较新解释器编写流程脚本的用户。
exrmetrics、exrmultipart 和 exrcheck 工具获得了诊断与正确性方面的修复，主要的解压路径同样如此。这些修改的作者是 Alex Khal。
平台。修复了 32 位 Linux（i686）和 s390x 上长期存在的构建与测试缺陷、低于 10.15 的 macOS 和 powerpc 上的构建问题，以及在 Windows 7 上的启动问题。

谁需要更新，有多紧急

从漏洞的构成来看，大部分问题都位于早已存在的代码中。15 项中只有两项与 ZSTD 压缩相关，后者随 9 月 3.5.0 的发布一同进入 3.5 系列；当时它在 deep 数据上带来的收益最大，文件比使用 ZIPS 时小 20–30%。其余缺陷涉及 DWA、B44、分块 deep 文件、文件头解析和 Python 模块。因此，放弃新的压缩格式大概收效有限：渲染和合成长期以来所经过的那部分库同样存在漏洞。

deep 图像的回归问题只涉及少数机器。基于 x86 和 ARM 的典型工作站以小端方式运行，并未遇到该问题。该修复对于为服务器及较为少见的硬件构建 OpenEXR 的人更为重要。

大多数艺术家不会直接安装 OpenEXR：这个库由 DCC 套件、合成软件、渲染器和查看器的开发者嵌入到各自的构建中。修复要到这些厂商发布更新后才会抵达工作岗位；发布材料中未给出时间表。能够自行行动的是流程 TD，以及拥有基于 OpenEXR Python 模块的自研工具或自行构建该库的工作室。对他们来说，优先迁移到 3.5.3 或 3.4.17 是有意义的，尤其是当这些工具处理来自外部来源的文件时。

他人的 EXR 文件最常从哪里到你手上？