【漏洞分析】iPhone 播放视频自动关机“奇葩”漏洞成因分析-安全客

预估稿费：500RMB（不服你也来投稿啊！）

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

传送门

一、说明

23号早上主要的网络媒体都发了一条新闻[iOS又曝新漏洞，播放特定视频导致自动关机（含演示视频））]，主要内容是：苹果iOS设备又被爆出新漏洞，播放一段特定的MP4视频，将导致设备重启。我们团队在第一时间拿到了视频样本（a92aaf9dc6307e5387cb3206e6faed48），并在设备上做了验证，发现播放视频确实会引起设备重启，并做了简单的技术层面的分析，本文主要介绍了我们分析的步骤与结论。

二、分析步骤

1、观察现象

首先以某种方式播放问题视频，我们采用的方式是写一个小程序。同时，我们知道 mediaserverd 进程是负责视频播放的后台服务。因此，在播放视频的过程中我们观察 mediaserverd 进程的 CPU 及内存的使用情况：

如上图，我们观察到在播放问题视频时，mediaserverd 的内存占用比较稳定，因此排除内存泄露。但是，CPU 占用非常高，初步猜测：问题视频会造成 mediaserverd 进程死循环。

另外，我们观察到在 CPU 接近 100% 的情况下，过一段时间 iOS 会崩溃，重启后我们可以拿到 Panic Log，主要内容如下：

{
  "build" : "iPhone OS 9.0.2 (13A452)",
  "product" : "iPhone7,1",
  …
  "date" : "2016-11-23 10:29:22.22 +0800",
  "panicString" : "Debugger message: WDT timeout",

iOS 崩溃的原因是 Watchdog 超时，基本验证了我们之前的猜测。

2、确定畸形视频范围

问题视频的总时长为5.01秒，每秒 26 帧，但是在播放前面几秒的视频时并不会造成 iOS 崩溃。为了便于后期分析，我们首先需要确认视频中哪些部分是畸形的。结合之前的观察我们知道：视频中畸形的数据在视频中的位置比较靠后，因此我们从后往前对视频进行裁剪，即：首先取出 [4.01, 5.01] 范围内的视频，然后播放、测试。我们发现 [4.01, 5.01] 这个范围内的视频就会造成 iOS 崩溃。之后，我们又取出 [0.00, 4.01] 这个范围内的视频进行播放、测试，发现这段范围内的视频并不会造成 iOS 崩溃。

最后，我们确认视频中的畸形数据存在于原始视频的最后 1 秒是中，即“秒拍”添加的片尾中：

注：不代表“秒拍”添加的所有片尾都有问题。

3、分析 iOS 崩溃日志

mediaserverd 进程 CPU 占用率 100%，问题代码可能在用户空间，也可能存在于内核空间。如果用户空间的代码存在问题，那么 mediaserverd 进程会被杀掉，但是我们观察到直至设备重启前 mediaserverd 进程一直存在。因此，问题代码很可能出在内核空间。

分析内核空间的问题，目前我们手里最直接的信息就是内核的崩溃日志，而内核的崩溃日志中的最有价值的部分就是崩溃线程的调用栈：

Kernel slide:     0x000000000ec00000
Kernel text base: 0xffffff8012c04000
Frame-01: lr: 0xffffff8012d04714  fp: 0xffffff8013120a70
Frame-02: lr: 0xffffff801328b474  fp: 0xffffff8013120f40
Frame-03: lr: 0xffffff80142c308c  fp: 0xffffff8013120fd0
Frame-04: lr: 0xffffff8013055f80  fp: 0xffffff8013120fe0
Frame-05: lr: 0xffffff8012cfb26c  fp: 0xffffff8013120ff0
Frame-06: lr: 0xffffff8012c3576c  fp: 0xffffff80008ab2a0
Frame-07: lr: 0xffffff8012f79d50  fp: 0xffffff80008ab2c0
Frame-08: lr: 0xffffff80143d69c4  fp: 0xffffff80008ab3f0
Frame-09: lr: 0xffffff80143e7cfc  fp: 0xffffff80008ab420
Frame-10: lr: 0xffffff80143e8070  fp: 0xffffff80008ab450
Frame-11: lr: 0xffffff80143e9044  fp: 0xffffff80008ab480
Frame-12: lr: 0xffffff80143e71fc  fp: 0xffffff80008ab4c0
Frame-13: lr: 0xffffff80143e7448  fp: 0xffffff80008ab520
Frame-14: lr: 0xffffff80143f1348  fp: 0xffffff80008ab550
Frame-15: lr: 0xffffff80143dec50  fp: 0xffffff80008ab680
Frame-16: lr: 0xffffff80143dd59c  fp: 0xffffff80008ab690
Frame-17: lr: 0xffffff8013061ee0  fp: 0xffffff80008ab820
Frame-18: lr: 0xffffff8012cdaa64  fp: 0xffffff80008ab950
Frame-19: lr: 0xffffff8012c18460  fp: 0xffffff80008aba30
Frame-20: lr: 0xffffff8012c2634c  fp: 0xffffff80008abad0
Frame-21: lr: 0xffffff8012cfd80c  fp: 0xffffff80008abba0
Frame-22: lr: 0xffffff8012cfc0f4  fp: 0xffffff80008abc90
Frame-23: lr: 0xffffff8012cfb1f0  fp: 0xffffff80008abca0
Frame-24: lr: 0x0000000198d34c30  fp: 0x0000000000000000

调用栈信息如上，我们首先需要把 lr 的地址映射到具体的内核中。由于，调用栈比较长，这里我们只是给出几个主要的栈帧信息：

Frame-1：保存崩溃信息并重启设备

Frame-8: 输出错误信息，同时可以确定出问题的内核模块为 AppleVXD393

4、寻找死循环

我们之前猜测内核中可能存在死循环，现在我们遍历崩溃时的调用栈，寻找死循环具体在什么位置。最后我们发现死循环应该在 Frame-14 中，其主要的伪代码如下：

__int64 __fastcall PRTS_AppleVXD393_Panic_Frame_14(__int64 a1, __int64 a2, int a3)
{
  ...
  for ( i = 1; ; ++i )
  {
    ...
    v17 = PRTS_AppleVXD393_Panic_Frame_13(v10);
    ...
    if ( !((unsigned __int8)(v21 ^ v22) | v20) )
      break;
    v12 = *(_QWORD *)(v10 + 12528);
  }
  ...
}

为了确认是这个函数出问题了，我们首先在 Frame-14 的上层函数中将对 Frame-14 的调用 Patch 调：