Featured image of post openjpeg_02:CVE-2016-7445
二进制安全

openjpeg_02:CVE-2016-7445

CVE-2016-7445

本文将介绍CVE-2016-7445这一漏洞的背景、原理和复现方式，仅为个人学习笔记，供大家学习参考。

申明：本工作是A.S.E (AI Code Generation Security Evaluation)开源项目的一部分，很荣幸能作为contributor参与这一开源项目，为大模型的安全评估做出贡献；

笔记汇总在CVE_Binary_Reproduction。

漏洞卡片

字段 内容
CVE-ID CVE-2016-7445
CWE-ID CWE-476:NULL Pointer Dereference
NVD公开日期 2016-10-03
评分 7.5 HIGH (CVSS v3)
影响组件 OpenJPEG (openjp2) ≤ 2.2.0
受影响模块 PNM/PPM 文件读取相关代码（命令行工具中的 src/bin/jp2/convert.c）
漏洞类型 未做充分校验导致的 NULL 指针解引用
利用后果 崩溃（拒绝服务），在图像处理管道上可被恶意或畸形图片触发
补丁 Commit f053508f6fc26aa95839f747bc7cbf257bd43996 (openjpeg)

背景介绍

  • OpenJPEG（openjp2）是 JPEG 2000（ISO/IEC 15444）的一种开源实现，包含编解码器与命令行工具（opj_compress、opj_decompress 等），广泛用于图像查看器、PDF 渲染器与医疗影像等领域。
  • PNM/PPM 的文本头部需要按顺序解析宽、高、最大值（depth）等字段；处理这些文本字段时的健壮性直接关系到对畸形输入的安全性。

漏洞原理分析

  • 触发点（观察到的行为）
    • 在用 opj_compress 读取畸形的 PPM/PNM 文件头时，解析函数在调用 skip_int / skip_white 之类的 辅助函数 进行跳过空白和解析整数后，没有对返回结果进行充分校验。报告与 ASan 输出显示崩溃发生在 convert.c 的 skip_white（原 issue 报告定位为 convert.c:1331），即对空指针进行了读取从而触发 SEGV。
  • 根本原因
    • 根本原因是 PNM/PPM 头部解析流程对中间返回值（指向解析缓冲区当前位置的 char*）的信任：当 skip_int 解析失败或到达输入末尾时，返回的指针可能为 NULL 或不再有效，而后续代码没有检测这一情况，继续在该指针上调用 skip_white/再次 skip_int 等操作，导致 NULL 指针解引用（CWE-476）。
  • 如何被利用（攻击面）
    • 攻击者只需提供一个特制/畸形的 PPM（PNM） 文件并诱使目标程序（使用受影响的 openjpeg/opj_compress）去读取该文件，即可触发崩溃（拒绝服务）。因此攻击面是所有接受或处理不受信任 PNM/PPM 输入的场景（命令行工具、图像处理服务、批量转换管道等）。

漏洞复现

环境准备

本次复现是在docker容器环境下进行的，保证了环境的精确、纯粹，我们可以随意指定依赖版本，而不会被主机的环境干扰。

首先，拉取openjpeg官方github仓库。

1

git clone https://github.com/uclouvain/openjpeg.git

然后，根据编译所需相关依赖创建docker镜像，注意依赖要尽量贴合当年的环境，以下是我使用的dockerfile内容。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/usr/bin/env bash
set -e

cd /workspace/openjpeg
BUILD_DIR="build_ASan"

# 1. 完全清理
rm -rf "$BUILD_DIR"
mkdir "$BUILD_DIR"

# 2. 强制 clang + ASan 渗透到所有阶段
export CC=clang
export CXX=clang++
export CFLAGS="-fsanitize=address -fno-omit-frame-pointer -g -O0"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-fsanitize=address"

# 3. 配置 + 编译
cd "$BUILD_DIR"
cmake .. \
  -DCMAKE_BUILD_TYPE=Debug \
  -DCMAKE_C_COMPILER="$CC" \
  -DCMAKE_CXX_COMPILER="$CXX" \
  -DCMAKE_C_FLAGS="$CFLAGS" \
  -DCMAKE_CXX_FLAGS="$CXXFLAGS" \
  -DCMAKE_EXE_LINKER_FLAGS="$LDFLAGS" \
  -DBUILD_SHARED_LIBS=OFF \
  -DBUILD_THIRDPARTY=ON

cmake --build . -- -j$(nproc)

echo "=== Build finished ==="
echo "Executable: $(pwd)/bin/opj_compress"

根据dockerfile，我们创建镜像。

1
2
3
4
5
6
7

# 在dockerfile所在目录下执行
docker build -t openjpeg_cve-2016-7445 .
# 检查是否创建成功
docker images
# 返回的images中含openjpeg_cve-2016-7445即创建完成
REPOSITORY                       TAG       IMAGE ID       CREATED        SIZE
openjpeg_cve-2016-7445          latest    07ad62f9e5e6   4 weeks ago    800MB

至此环境准备就完成了。

编译/触发

首先，使用先前创建的镜像启动容器，建议使用docker容器挂载宿主机目录，方便进行文件的观测和修改。

1
2
3
4
5
6
7

# 挂载目录替换成自己宿主机的实际路径，保证openjpeg项目文件夹也在其下
docker run -it --rm --name openjpeg_cve-2016-7445 \
  -v /mnt/d/A.S.E/benchmark-project/openjpeg:/workspace \
  openjpeg_cve-2016-7445   /bin/bash
# -rm 选项表示容器退出后自动删除
# --name 指定容器名字
# /bin/bash 指定命令行环境

宿主机目录会被挂载到容器的/workspace目录下，注意所有改变也会同步到宿主机目录上。

进入容器后，我们先将项目切换到修复前版本。

1
2
3

cd openjpeg
# 切换到修复前一个commit
git checkout f053508f6fc26aa95839f747bc7cbf257bd43996^

接着我们编译出供漏洞复现使用的组件，注意需要启用 ASan 与 debug 编译标志以获得清晰崩溃信息，以下是我撰写使用的编译脚本setup.sh。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/usr/bin/env bash
set -e

cd /workspace/openjpeg
BUILD_DIR="build_ASan"

# 1. 完全清理
rm -rf "$BUILD_DIR"
mkdir "$BUILD_DIR"

# 2. 强制 clang + ASan 渗透到所有阶段
export CC=clang
export CXX=clang++
export CFLAGS="-fsanitize=address -fno-omit-frame-pointer -g -O0"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-fsanitize=address"

# 3. 配置 + 编译
cd "$BUILD_DIR"
cmake .. \
  -DCMAKE_BUILD_TYPE=Debug \
  -DCMAKE_C_COMPILER="$CC" \
  -DCMAKE_CXX_COMPILER="$CXX" \
  -DCMAKE_C_FLAGS="$CFLAGS" \
  -DCMAKE_CXX_FLAGS="$CXXFLAGS" \
  -DCMAKE_EXE_LINKER_FLAGS="$LDFLAGS" \
  -DBUILD_SHARED_LIBS=OFF \
  -DBUILD_THIRDPARTY=ON

cmake --build . -- -j$(nproc)

echo "=== Build finished ==="
echo "Executable: $(pwd)/bin/opj_compress"

编译成功

执行完毕后，需要用到的编码器组件opj_compress应当在以下路径。

1
2
3

# 检查opj_compress是否存在
root@1877c59a83ec:/workspace# ls /workspace/openjpeg/build_ASan/bin/opj_compress
/workspace/openjpeg/build_ASan/bin/opj_compress

接下来就可以结合poc触发文件，参考bug_report的中的漏洞触发方式进行漏洞复现。

在report中，触发命令格式如下：

1
2
3
4
5

# $OPJ_COMPRESS 编码器路径
# $POC_RAW poc文件路径
# $OUT_FILE 编码输出文件路径
"$OPJ_COMPRESS" -i "$POC_RAW" -o "$OUT_FILE" 
/workspace/openjpeg/build_ASan/bin/opj_compress -i /workspace/poc/2016-7445.ppm -o /tmp/null.j2k

我使用的poc文件链接附上：2016-7445.ppm

调整路径并执行后成功触发漏洞，显著标志为 SEGV on unknown address，具体结果如下：

触发漏洞

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

root@89dfa8253bd0:/workspace# /workspace/openjpeg/build_ASan/bin/opj_compress -i /workspace/poc/2016-7445.ppm -o /tmp/null.j2k

ASAN:DEADLYSIGNAL
=================================================================
==1646==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000052079f bp 0x7ffce9c5c120 sp 0x7ffce9c5c0b0 T0)
    #0 0x52079e  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x52079e)
    #1 0x520457  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x520457)
    #2 0x518b25  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x518b25)
    #3 0x5161c4  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x5161c4)
    #4 0x4fc3a3  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x4fc3a3)
    #5 0x7685dc91e83f  (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
    #6 0x429e38  (/workspace/openjpeg/build_ASan/bin/opj_compress+0x429e38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/workspace/openjpeg/build_ASan/bin/opj_compress+0x52079e) 
==1646==ABORTING

当我们切换到修复后版本尝试漏洞复现：

1
2
3
4

cd openjpeg
git checkout f053508f6fc26aa95839f747bc7cbf257bd43996
cd ..
./setup.sh && /workspace/openjpeg/build_ASan/bin/opj_compress -i /workspace/poc/2016-7445.ppm -o /tmp/null.j2k

这次就被补丁提前拦截了。

1
2
3

=== Build finished ===
Executable: /workspace/openjpeg/build_ASan/bin/opj_compress
Unable to load pnm file

PoC分析

我们来分析一下PoC文件是如何触发漏洞的，已知该漏洞的原理是：

  • PoC 通过构造一个在 PPM 文本头中缺失或畸形的字段（例如使得在解析宽度/高度/最大色深时，skip_int 或者后续的 skip_white 在某一步失败）来触发路径：第一次 skip_int/skip_white 可能使内部指针变为 NULL 或指向缓冲区末尾，随后代码未检测便继续使用该指针，从而触发 NULL 解引用。

我们使用xxd -g 1 -l 512 2016-7445.ppm来对poc文件进行具体分析：

  • 文件确实是 P6（二进制 PPM），尺寸为 256 x 149，maxval 是 255；
  • 头部包含注释 “# OpenJPEG-2.0.0”（从 offset 0x03 起可见）。
  • 在注释文字之后、宽高数字 “256 149” 之前出现了一个非 ASCII 字节 0x8A（见 00000010 行），即注释并未以常见的换行（0x0a）结束，而是被 0x8A 字节分隔，导致解析器无法按预期识别下一个数字 token。

那么为什么这会触发漏洞呢？

  • PNM/PPM 解析器通常的逻辑：读取 magic (“P6”)，跳过注释到换行，跳过空白（skip_white），再用 skip_int 读取 width、height、maxval 等。
  • 而PoC 的头部有一个非标准字节 0x8A 放在注释末尾和宽度字段之间：这会导致解析器不能发现预期的换行或空白分隔，从而使 skip_int/skip_white 在寻找下一个数字时失败（到达缓冲末尾或遇到非法字符），返回 NULL 或不可用的指针。
  • 代码在后续没有对 skip_int/skip_white 的返回值做严格检查（issue 指出 convert.c 的某些行在调用后未检查变量 s），于是继续在 NULL 指针上操作，最终在 skip_white（convert.c:1331）处解引用 NULL，触发 SIGSEGV。这与前文的 ASan 报告完全一致。

汇总可验证事实：issue 中 ASan 栈回溯指向 convert.c 的 skip_white，报告分析指出 convert.c 的若干行（在调用 skip_int 后）没有检查变量 s 的值；上述PoC 文件能稳定触发该崩溃。

补丁分析

修复commit详见：Fix PNM file reading (#847) · uclouvain/openjpeg@f053508

  1. 主要改动
    • 对 PNM/PPM 读取逻辑增加了对 skip_int/skip_white 等返回值的检查：在解析 width/height/depth 等字段后会判断解析是否成功，若失败则不会继续使用返回的指针而是返回错误。
    • 在读到图像尺寸和深度后加入了合法性校验（例如检查宽高是否为 0 或非法值），并在不合法时返回加载错误。
    • 将解析失败或不合法输入的路径改为返回失败（并由上层打印如 “Unable to load pnm file” 的提示），避免继续进入会触发 NULL 解引用的代码路径。
  2. 为什么能修复问题
    • 补丁通过在关键点（skip_int/skip_white 返回后）添加空指针/返回值检查，阻止后续对可能为 NULL 的指针进行解引用，从根本上消除了导致 SEGV 的未检查 NULL 使用路径。修复后的行为是在发现解析异常时尽早中止并返回错误，从而避免崩溃。
  3. 补丁的局限与建议
    • 局限：补丁修复了 PNM/PPM 读取路径中已发现的未检查返回值问题，但并不能替代对所有输入解析路径统一的防御性编程策略。类似的未检查返回值在项目中其他解析代码处仍有可能存在。
    • 建议：
      • 在所有格式解析函数处统一进行返回值与边界检查（防御式编程）。
      • 为畸形/恶意 PNM/PPM 输入添加回归测试（将触发该问题的 PoC 纳入 CI），以防回归。
      • 对外部库接口在出错时返回可检测的错误码，避免工具端直接崩溃或不可预测行为。

复现镜像

以上复现过程已打包为docker镜像，可通过以下命令拉取：

1

docker pull choser/openjpeg_cve-2016-7445:latest

内含：

  • openjpeg（项目文件夹）
  • setup.sh
  • image_status_check.sh
  • test_case.sh
  • poc.sh
  • poc文件

首先进入项目文件夹，按需切换到修复前/后版本：

1
2
3
4
5

cd openjpeg
# 切换到修复前一个commit
git checkout f053508f6fc26aa95839f747bc7cbf257bd43996^
# 切换到修复commit
git checkout f053508f6fc26aa95839f747bc7cbf257bd43996

然后按顺序执行四个脚本，即可复现和验证漏洞，预期结果为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 在修复前/后两个版本
./setup.sh && ./image_status_check.sh && ./test_case.sh
# 都应成功编译，并且可执行文件通过基本功能验证
=== Build finished ===
Executable: /workspace/openjpeg/build_ASan/bin/opj_compress
[A.S.E] image startup successfully
[A.S.E] test case passed
# 在修复前/后版本
./poc.sh
# 修复前版本
[A.S.E] vulnerability found
# 修复后版本
[A.S.E] vulnerability not found

总结和启示

  • 总结和启示：对任何来自不受信任源（文件、网络等）的输入都必须进行严格的返回值与边界检查；一次对解析函数返回值的忽视即可导致 NULL 指针解引用和服务拒绝。
  • 实践建议：尽快升级到包含 commit f053508f6… 的版本；在代码库中系统地审计其他类似文本/流解析逻辑并增加畸形输入的回归测试。

参考链接

CVE
Licensed under CC BY-NC-SA 4.0
© 2023 - 2025 Ch0ser
© 2023-2025 Ch0ser. All Rights Reserved.
使用 Hugo 构建
主题 Stack 由 Jimmy 设计