xpc-string-leak 是 libxpc 中越界内存读取的概念验证漏洞利用程序。该漏洞利用利用该漏洞从 diagnosticd 中读取越界堆内存，diagnosticd 是一个未沙盒化的 root 进程，具有 task_for_pid-allow 权限。
在 macOS 10.13.5 和 iOS 11.4 上，函数 _xpc_string_deserialize 在通过 _xpc_string_create 创建 XPC 字符串对象之前，没有验证反序列化的字符串是否具有正确的长度。如果随后将 XPC 字符串序列化到另一个 XPC 消息中，这可能导致类似 Heartbleed 的越界堆读取。
以下是 _xpc_string_deserialize 的实现，使用 IDA 反编译：
OS_xpc_string *__fastcall _xpc_string_deserialize(OS_xpc_serializer *xserializer)
{
OS_xpc_string *xstring; // rbx@1
char *string; // rax@4
char *contents; // [rsp+8h] [rbp-18h]@1
size_t size; // [rsp+10h] [rbp-10h]@1 MAPDST
xstring = 0LL;
contents = 0LL;
size = 0LL;
if ( _xpc_string_get_wire_value(xserializer, (const char **)&contents, &size) )
{
if ( contents[size - 1] || (string = _xpc_try_strdup(contents)) == 0LL )
{
xstring = 0LL;
}
else
{
xstring = _xpc_string_create(string, size - 1);
LOBYTE(xstring->flags) |= 1u;
}
}
return xstring;
}
_xpc_string_deserialize 首先调用 _xpc_string_get_wire_value 来获取指向字符串数据的指针以及字符串头部报告的序列化大小。然后 _xpc_string_deserialize 检查字符串在其报告大小的末尾是否有空终止符，但关键的是没有检查数据开头是否没有空终止符。最后，它在堆上创建字符串的副本，并使用 _xpc_string_create 创建 OS_xpc_string 对象。
以下是 _xpc_string_create 的反编译代码：
OS_xpc_string *__fastcall _xpc_string_create(const char *string, size_t length)
{
OS_xpc_string *xstring; // rax@1
xstring = (OS_xpc_string *)_xpc_base_create(&OBJC_CLASS___OS_xpc_string, 16LL);
if ( (((_DWORD)length + 4) & 0xFFFFFFFC) + 4 < length )
_xpc_api_misuse("Unreasonably large string");
xstring->wire_length = ((length + 4) & 0xFFFFFFFC) + 4;
xstring->string = string;
xstring->length = length;
return xstring;
}
_xpc_string_create 信任 _xpc_string_deserialize 提供的长度值，并在 OS_xpc_string 对象中设置相应的字段。此时，反序列化的字符串的 length 字段可能大于分配的字符串数据。
理论上，这可用于触发那些使用 xpc_string_get_length 获取字符串长度的服务中的内存损坏，但这种模式似乎不常见。一种功能较弱但更实用的利用策略是让字符串被重新序列化并发送回给我们，从而为我们提供一个类似 Heartbleed 的窗口，窥探受害者进程的内存。
这是 _xpc_string_serialize 的实现：
void __fastcall _xpc_string_serialize(OS_xpc_string *string, OS_xpc_serializer *serializer)
{
int type; // [rsp+8h] [rbp-18h]@1
int size; // [rsp+Ch] [rbp-14h]@1
type = *((_DWORD *)&OBJC_CLASS___OS_xpc_string + 10);
_xpc_serializer_append(serializer, &type, 4uLL, 1, 0, 0);
size = LODWORD(string->length) + 1;
_xpc_serializer_append(serializer, &size, 4uLL, 1, 0, 0);
_xpc_serializer_append(serializer, string->string, string->length + 1, 1, 0, 0);
}
OS_xpc_string 的 length 参数在序列化时被信任，这意味着许多字节会从堆中读取到序列化消息中。如果反序列化的字符串短于其报告的长度，消息将被越界堆数据填充。
我们仍然仅限于利用那些将部分 XPC 消息反射回客户端的 XPC 服务，但这更为常见。例如，在 macOS 和 iOS 上，diagnosticd 是一个有希望的候选者，它恰好是未沙盒化、root 且具有 task_for_pid 权限的。Diagnosticd 负责处理诊断消息（例如 os_log 生成的消息），并将它们流式传输给有兴趣接收这些消息的客户端。通过注册以接收我们自己的诊断流，然后发送一个字符串比预期短的诊断消息，我们可以获得 diagnosticd 堆中部分数据的快照，这有助于在该进程中实现代码执行。
要构建，请运行 make。有关各种构建选项，请参阅 Makefile 的顶部。
通过命令行指定泄漏大小来运行漏洞利用：
$ ./xpc-string-leak 0x40
0x2000000000000000 0xe00007ff39bf0992
0x00007fff56858570 0x00007fff7ed23d0e
0x0000000000000000 0x0000000000000000
0x00007fff7ed52be2 0x00007fff7ed29ed6
泄漏大小必须是 8 的倍数且至少为 16。
xpc-string-leak 代码已发布到公共领域。出于礼貌，如果您引用或使用此代码的任何部分，请注明我的出处。
我于 2018 年初（1 月或 2 月）发现此漏洞，但直到 5 月才想起进行调查。我于 5 月 9 日向 Apple 报告了该问题，它被分配了 CVE-2018-4248，并于 7 月 9 日在 iOS 11.4.1 和 macOS 10.13.6 中进行了修补。
Brandon Azad