苹果手机ios系统 “奇葩”漏洞成因分析

一、说明

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" : "window 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 调：

Patch日志：

在 Patch 了相关代码之后，我们播放视频发现 iOS 不会崩溃。

同时，为了排除 Frame-14 的下层函数出现问题，我们在 Frame-14 中对下层函数的调用 Patch掉，如下图：

在 Patch 调对下层函数调用后，播放视频还是会造成 iOS 崩溃。总结起来，我们这里使用了注释代码的手段来确定问题代码的范围，最后我们确定：出问题的代码在崩溃时的调用栈的第 14 帧函数中，畸形的视频数据造成该函数死循环。

三、结论

由于时间有限，经过简单分析，目前的结论是：播放含有畸形数据的样本视频，会造成 iOS 内核中负责视频解码的模块进入死循环，进而引起内核 WatchDog 超时，造成内核重启。针对该样本，目前没发现更多危害。