Project Zero 关于 Fuzzing ImageIO 的研究

这篇博客文章讨论了在新的上下文中的图像格式解析器中的漏洞：流行的Messenger应用程序中的无交互代码路径。这项研究的重点是Apple生态系统及其提供的图像解析API：ImageIO框架。我们发现了图像解析代码中的多个漏洞，并将其报告给Apple或相应的开源图像库维护者，然后进行了修复。在这项研究期间，针对闭源二进制文件的轻量级且开销低的引导Fuzzing方法得以实施，并与本博文一起发布。

整个博客中描述的漏洞可以通过Messenger来访问，但不属于其代码库。因此，供应商需要修复它们。

0x01  基础介绍

在对Messenger应用进行逆向时，我在无需用户交互就可以到达的代码路径上遇到了以下代码（手动反编译为ObjC并稍作简化）：

 NSData* payload = [handler decryptData:encryptedDataFromSender, ...];
 if (isImagePayload) {
     UIImage* img = [UIImage imageWithData:payload];
     ...;
 }

此代码解密从发送方收到的作为传入消息一部分的二进制数据，并从中实例化UIImage实例。

 https://developer.apple.com/documentation/uikit/uiimage?language=objc

然后，UIImage构造函数将尝试自动确定图像格式。之后，将接收到的图像传递给以下代码：

 CGImageRef cgImage = [image CGImage];
 CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
 CGContextRef cgContext = CGBitmapContextCreate(0, thumbnailWidth, thumbnailHeight, ...);
 CGContextDrawImage(cgContext, cgImage, ...);
 CGImageRef outImage = CGBitmapContextCreateImage(cgContext);
 UIImage* thumbnail = [UIImage imageWithCGImage:outImage];

此代码的目的是渲染输入图像的较小尺寸的版本，独步以用作用户通知中的缩略图。毫不奇怪，在其他Messenger应用中也可以找到类似的代码。本质上，如上所示的代码将Apple的UIImage图像解析和CoreGraphics图像渲染代码转换为0click攻击面。

 https://googleprojectzero.blogspot.com/2020/01/remote-iphone-exploitation-part-1.html

如果满足以下先决条件，则可以使用所描述的技术来利用内存破坏漏洞：

1. 一种从处理邮件的过程发送的传输形式；

2. 每次启动ASLR至少需要一些内存映射；

3. 自动重启服务。

在那种情况下，该漏洞可能例如用于破坏指向ObjC对象（或类似对象）的指针，然后构造一个崩溃Oracle以绕过ASLR，然后再执行代码。

在当前的攻击场景中，所有前提条件都得到满足，因此促使人们对暴露图像解析代码的鲁棒性进行一些研究。查看UImage的文档，可以发现以下句子：“使用图像对象表示各种图像数据，并且UIImage类能够管理基础平台支持的所有图像格式的数据”。这样，下一步就是确切确定底层平台支持哪些图像格式