Featured image of post openjpeg_05:CVE-2018-5785
二进制安全

openjpeg_05:CVE-2018-5785

CVE-2018-5785

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

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

笔记汇总在CVE_Binary_Reproduction。

漏洞卡片

字段 内容
CVE-ID CVE-2018-5785
CWE-ID CWE-190: Integer Overflow
NVD公开日期 2018-01-19
评分 6.5 MEDIUM (CVSS v3)
影响组件 openjp2 <= 2.2.0（在 2.3/master 上发现）
受影响模块 openjp2（JPEG2000 编码器）
漏洞类型 整数溢出 / 未定义行为，可能导致缓冲区破坏（Heap overflow）或崩溃
利用后果 远程代码执行 / DoS
补丁 Commit ca16fe55014c57090dd97369256c7657aeb25975 (openjpeg)

背景介绍

  • OpenJPEG（openjp2）是 JPEG 2000（ISO/IEC 15444）的一种开源实现，包含编解码器与命令行工具（opj_compress、opj_decompress 等），广泛用于图像查看器、PDF 渲染器与医疗影像等领域。
  • 漏洞发生在 BMP 转换相关代码（convertbmp）与后续的编码初始化路径中：当输入 BMP 声明使用 BI_BITFIELDS（即自定义颜色掩码）的压缩模式，但提供了“零”掩码或由于头部解析不完整导致掩码保持为 0 时，后续代码会依据掩码推断颜色位宽/精度并执行位移运算，可能触发未定义行为或整数溢出。

漏洞原理分析

  • 触发点（观察到的行为）

    • BMP 解析阶段（convertbmp）得到的颜色掩码（bitmask）为 0（两类情况：BMP 真是把掩码设为 0，或 info header 的 size 太小导致掩码字段没被读取、仍为初始值 0）。
    • 程序根据掩码计算“精度（prec）”或颜色位宽。常见的计算方式是“统计掩码所含的位数”或“从掩码推断有效位宽”。如果掩码为 0，统计结果通常会留为 0（loop 没进入），或后续对 0 做算术操作可能产生负值。
    • 后续代码使用 prec 来做位移运算，例如 1 « (prec - 1)。如果 prec 为 0，则 prec - 1 = -1。C 语言中对负数进行左移是未定义的；在某些编译器/运行时报告中，负数会先按无符号转换（例如 -1 转为 0xFFFFFFFF），因此变成 1 « 4294967295，这就是先前看到的 UBSAN 报告。、

    为什么会显示 4294967295？

    • 在打印运行时错误时，UBSAN 报告的是 shift exponent 的实际 unsigned 展示：-1 以 32 位无符号表示就是 2^32 - 1 = 4294967295。于是看到 “shift exponent 4294967295 is too large for 32-bit type ‘int’”。

  • 根本原因（两类问题共同导致）

    • BMP 解析（convertbmp）在处理 BI_BITFIELDS 时，当 info header 的 size 字段较小时（<=56），没有把 mask 字段设置为有效默认值，导致掩码保持初始 0 值；
    • 上游编码器在依赖这些掩码/精度信息时，未对掩码为 0 或得到非法精度值的情况做足够的边界检查，从而进行了非法位移/整数计算。

  • 如何被利用（攻击面）

    • 攻击者可以构造一个 BMP 文件，设置 compression 字段为 BI_BITFIELDS（3），且使位掩码区域解析为 0（或通过故意设置 header size 导致掩码不被正确解析）。把该文件输入到受影响版本的 opj_compress（或任何调用相关解析/编码路径的组件）即可触发运行时错误或内存破坏。利用链可能导致程序崩溃（DoS）或在特定条件下触发堆/栈覆盖导致 RCE。

漏洞复现

环境准备

本次复现是在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
34
35
36
37
38

FROM ubuntu:16.04

# 设置非交互式安装
ENV DEBIAN_FRONTEND=noninteractive

# 安装基础依赖
RUN apt-get update && apt-get install -y \
    build-essential \
    cmake \
    git \
    clang \
    gcc \
    g++ \
    libc6-dev \
    libtiff5-dev \
    libpng-dev \
    libjpeg-dev \
    zlib1g-dev \
    libssl-dev \
    pkg-config \
    wget \
    vim \
    && rm -rf /var/lib/apt/lists/*

# 安装 AddressSanitizer（ASan）支持的编译器（clang）
RUN apt-get update && apt-get install -y \
    clang-3.8 \
    && rm -rf /var/lib/apt/lists/*

# 设置默认编译器为 clang（用于 ASan）
ENV CC=clang-3.8
ENV CXX=clang++-3.8

# 设置工作目录
WORKDIR /workspace

# 保持容器运行
CMD ["tail", "-f", "/dev/null"]

根据dockerfile，我们创建镜像。

1
2
3
4
5
6
7

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

至此环境准备就完成了。

编译/触发

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

1
2
3
4
5
6
7

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

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

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

1
2
3

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

接着我们编译出供漏洞复现使用的组件，注意需要启用 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=undefined -g -O0"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-fsanitize=undefined"

# 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

# opj_compress 编码器路径
# $FILE poc文件路径
# null.j2k 编码输出文件路径
/workspace/openjpeg/build_ASan/bin/opj_compress -n 1 -i /workspace/poc/2018-5785.bmp -o /tmp/null.j2k

我使用的poc文件链接附上：2018-5785.bmp

调整路径并执行后成功触发漏洞，在启用 UBSAN/ASan 并使用修复前的 commit（修复前版本）时会看到诸如： runtime error: shift exponent 4294967295 is too large for 32-bit type ‘int’ 以及随后的一些 signed integer overflow 报错或崩溃行为，具体结果如下：

触发漏洞

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

root@f60c03822e5e:/workspace# /workspace/openjpeg/build_ASan/bin/opj_compress -n 1 -i /workspace/2018-5785.bmp -o /tmp/null.j2k

Failed to open /workspace/2018-5785.bmp for reading !!
Unable to load bmp file
root@f60c03822e5e:/workspace# /workspace/openjpeg/build_ASan/bin/opj_compress -n 1 -i /workspace/poc/2018-5785.bmp -o /tmp/null.j2k

/workspace/openjpeg/src/lib/openjp2/j2k.c:7309:48: runtime error: shift exponent 4294967295 is too large for 32-bit type 'int'
[INFO] tile number 1 / 1
/workspace/openjpeg/src/lib/openjp2/tcd.c:2388:32: runtime error: signed integer overflow: 0 - -2147483648 cannot be represented in type 'int'
/workspace/openjpeg/src/lib/openjp2/mct.c:109:31: runtime error: signed integer overflow: -2147483648 * 2 cannot be represented in type 'int'
/workspace/openjpeg/src/lib/openjp2/mct.c:109:36: runtime error: signed integer overflow: -2147483648 + -2147483648 cannot be represented in type 'int'
[INFO] Generated outfile /tmp/null.j2k
encode time: 3 ms

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

1
2
3
4

cd openjpeg
git checkout ca16fe55014c57090dd97369256c7657aeb25975
cd ..
./setup.sh && /workspace/openjpeg/build_ASan/bin/opj_compress -n 1 -i /workspace/poc/2018-5785.bmp -o /tmp/null.j2k

在应用补丁（commit ca16fe55…）后，BMP 解析层会拒绝此类“intentional 0 bitmasks”情形，从而在早期阻断处理流程、避免触发后续未定义行为。

补丁生效

1
2
3
4
5
6

=== Build finished ===
Executable: /workspace/openjpeg/build_ASan/bin/opj_compress

[INFO] tile number 1 / 1
[INFO] Generated outfile /tmp/null.j2k
encode time: 3 ms

PoC分析

我们来分析一下PoC文件是如何触发漏洞的：

  • PoC 的触发方式集中在：
    • BMP header 指定 compression = BI_BITFIELDS；
    • info header size 被设置为导致 bitmasks 未被填充（或直接填为 0）的值；
    • 解析后，颜色通道的掩码为 0，导致计算精度时的循环/移位基于 0 值得出不合理的精度数值；
    • 这个不合理的精度用于位移计算（如 1 « (prec - 1)），触发左移越界或整数溢出/未定义行为。
  • 简单来说，PoC 是通过“合法字段组合但语义上不合理”的 BMP 来触发解析与后续处理的边界条件，从而诱发 UB。

补丁分析

修复commit详见:https://github.com/hlef/openjpeg/commit/ca16fe55014c57090dd97369256c7657aeb25975

  1. 主要改动
    • 在 BMP 解析逻辑（bmp_read_info_header / convertbmp）中增加检查：当 BMP 声明使用 BI_BITFIELDS 且位掩码全为 0 的情况时，拒绝此类文件并返回错误。对 32-bit 情形增加了与已有 16-bit 情形类似的默认值/校验处理。
    • 在注释中提到：如果 header size >= 56 且明确存在意图性的 0 掩码，当前补丁同样会拒绝，未来可考虑实现对 0 掩码的正确支持（而不是简单拒绝）。
  2. 为什么能修复问题
    • 补丁在尽早阶段检测到“掩码为 0”的异常情况，阻止这类输入继续进入后续编码初始化与位移运算路径，从根本上避免了基于未初始化/默认 0 掩码计算出的非法精度值被用于左移等敏感操作，从而防止整数溢出或未定义行为。
  3. 补丁的局限与建议
    • 局限：补丁采取的是“拒绝处理”策略（fail-fast），即对这类特殊/不规范的 BMP 文件返回错误，而不是尝试正确恢复或推断掩码含义。这会降低对某些非标准 BMP 的兼容性（但更安全）。
    • 建议：更理想的长期解决方案是根据 BMP 规格或实际常见实现，针对 0 掩码情形实现合理的回退机制（例如使用标准默认掩码或从 bit count 推断掩码），并在解析处对所有精度与位移操作加严格的边界检查以防止任何位移越界或整型溢出。

复现镜像

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

1

docker pull choser/openjpeg_cve-2018-5785:latest

内含：

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

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

1
2
3
4
5

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

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

 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

总结和启示

  • 这类问题本质上是“输入解析层的边界处理不严 + 在后续使用这些边界值时缺乏防御性编程”的组合。解析层应当对不符合预期的字段（例如 0 掩码）进行明确校验或提供安全的默认值，使用它们的后续代码应当假设输入可能被篡改或不正确，从而提前做边界检查（例如在做 1 « n 之前确保 n 在可接受范围内）。
  • 对图像库这样的库来说，面对格式上各种奇异/非标准的文件时，应优先选择拒绝不安全的输入而不是尝试“容错”地继续解析，除非能保证安全的恢复逻辑。
  • 在安全上下文中，使用 UBSAN/ASan/静态分析工具能帮助发现“常见但微妙”的未定义行为（如移位越界、整型溢出），并促使在输入解析与数值计算处加入必要的断言或校验。

参考链接

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