xz-utils后门漏洞 CVE-2024-3094 分析

360漏洞研究院 360漏洞研究院

事件背景

3月29日，微软PostgreSQL开发人员Andres Freund在oss-security上公告^[1]他发现开源项目xz-utils存在后门漏洞。该项目遭到供应链攻击，项目维护者jiaT75（jia Tan）通过上传二进制测试文件和篡改编译脚本，使得编译过程中恶意二进制文件会替换原有文件，导致编译输出与公开的源码不匹配。

其中liblzma库会通过IFUNC劫持sshd，添加后门以实现远程代码执行。该漏洞CVSS评分10分，受到影响的liblzma版本包括：5.6.0和5.6.1。

后门漏洞样本分析

本文对该后门漏洞进行了动静态分析，分享了我们整个漏洞的复现和分析的过程，有以下新进展：

1.定位了两处RCE点（调用system()）。

2.恢复了部分关键对象，可以确定后门程序调用了哪些系统库函数。

｜样本获取

目前xz-utils项目仓库已经无法访问，你可以通过以下方式获取样本：

1. Andres Freund在邮件列表中提供了二进制文件样本liblzma_la-crc64-fast.o.gz；

2. 从Debian仓库^[2]下载xz源代码；

｜样本分析

此次攻击流程如下：

1.在编译阶段插入恶意代码；

2.执行阶段构造后门，通过IFUNC劫持sshd进程；

3.触发后门阶段，在特定条件下，通过system实现RCE；

1. 编译阶段注入恶意代码

攻击者将看似测试的混淆代码推送到数据压缩库liblzma的构建过程中。

在XZ构建过程中，会调用关键脚本build-to-host.m4。在其中会嵌入一个混淆的脚本，与配置的脚本在一起执行。这个注入的脚本在模块xz-utils和liblzma生成MakeFiles过程中发挥着重要作用^[3]。

另外，liblzma的符号会在许多其他库之前得到解析，包括sshd二进制文件中的符号。在解析符号后，由于编译标志的GOT将被重新映射为只读页面权限-Wl,-z,relro。所以，为了使得恶意代码能够解析尚未加载的库中的符号，后门会在动态链接器中安装挂钩。这个钩子函数从_dl_audit_symbind中被调用，后门将RSA_public_decrypt@....plt的值更改为指向其自己的代码。

编译分为三个阶段^[4]：

（1）通过M4编译宏，还原恢复恶意数据：

m4/build-to-host.m4文件里有一些相关的代码片段：

从tests/files/bad-3-corrupt_lzma2.xz文件中读取的字节被输出到标准输入输出。在读取完所有内容后，还会添加一个新行(\n)。

第二步是运行tr（转换，就像是“将字符映射到其他字符”，或者“将字符替换为目标字符”），基本上是将选定的字符（或字节值）更改为其他字符（其他字节值）。于是，我们有tr "\t -" " \t-", 它在从tests/files/bad-3-corrupt_lzma2.xz文件流式传输的字节中进行以下替换：

这实际上是“修复”了bad-3-corrupt_lzma2.xz，使其再次形成一个正确的xz流。在这个阶段的最后一步中，修复后的xz字节流被提取。

（2）通过Bash脚本，提取和合并恶意数据：

该过程包括从一个压缩文件读取字节，通过一系列操作（如字符转换和筛选）来修正和提取数据。

第二阶段的提取代码，这包括一个复杂的导出语句export i=...。这个命令基本上定义了一个函数，它会在后面的步骤中被调用。

第二阶段提取的第一步是解压缩一个压缩文件，然后这个解压的输出会作为下一步的输入。接下来，执行一个由多个步骤组成的函数i，通过eval $i调用。这个函数主要是一系列的命令，用来处理数据流，要么提取（输出）数据的特定部分，要么跳过（忽略）数据的特定部分。在数据处理的开始，我们会跳过一些数据，比如忽略文件的前1024字节。这个过程反复进行，交替跳过和提取数据直到文件结束。如果文件的开始部分是由重复的字符构成，之后是一些二进制数据。我们通过这种方式去除空白区域，仅合并包含实际数据的区域。

简而言之，这个过程涉及解压缩数据，逐步处理和提取重要部分，最终得到准备好的数据以进行下一步的操作。

（3）修改编译过程，插入恶意代码：

以上脚本，通过在项目的测试文件夹中搜索包含特定签名的文件，脚本可以定位并执行隐藏于这些文件中的额外脚本或代码。这允许攻击者在不直接修改原始有效payload携带文件的情况下，增加新的恶意功能。

通过一系列精心设计的命令，在一个特定的.o文件（liblzma_la-crc64-fast.o）中嵌入恶意代码。

2. 执行阶段构造后门

liblzma_la_crc64_fast.o中get_cpuid()非常可疑。正常情况下，该函数会内联到代码中，GCC源码如下：

而后门程序实现如下：

看上去sub_A750()应该是_get_cpuid_max()，但实际上它的逻辑不止如此：

当dword_CB60为1时，会调用Llzma_block_param_encoder_0()，该函数是攻击的入口。这里使用了IFUNC技术，liblzma库在加载时，加载器会调用resolver函数，crc32_resolve()和crc64_resolve()这两个函数均会调用get_cpuid()。crc32_resolve()调用时，dword_CB60由0变为1。crc64_resolve()调用时，由于dword_CB60已经为1，后门程序会执行Llzma_block_param_encoder_0()。该函数最终会调用sub_3A10()，后者会检查当前进程是否为sshd，如果是sshd且环境变量符合要求，才会进行攻击：

Lsimple_coder_update_0()的功能是通过一个状态自动机来识别字符串，如果是已知字符串，返回该字符串的ID，如果没有则返回0。sub_3A10()先将当前进程的argv[0]（/usr/sbin/sshd）传入，然后将结果与0x108进行比较。如果不是0x108，则当前进程不是sshd，后门程序直接返回。

对Lsimple_coder_update_0()下断点可以看到，rdi第一个参数为“/usr/sbin/sshd”的情况。