iOS 表情符号拒绝服务漏洞详情披露(CVE-2018-4290)

阅读量    72553 | 评论 2   稿费 160

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

前言

在我们深入讨论之前,请注意:

  • 这个bug只是拒绝服务(相对于远程编码执行)。
  • 这个bug仅影响某些“无区域”配置中的iOS设备。
  • 这个bug在iOS 11.4.1已被修补为CVE-2018-4290。

话虽如此,这个bug还是可以远程触发的,而且可以导致受影响的设备上任何正在处理远程消息(iMessage、Facebook Messenger、WhatsApp等)的iOS应用程序都会崩溃!

 

背景

“Patrick,我想中国黑了我的iPhone”

虽然我通常会对这种难以置信的情景一笑置之,但我正在研究我的情绪智力,耐心地询问为什么我的台湾朋友会这样想。

她声称,每当她输入台湾或更糟的词时,都会收到一条带有台湾旗帜(🇹🇼)的消息,这会让她的iOS设备上的应用程序崩溃。

我仍然有点怀疑,但如下所示,这正是正在发生的事情!

我给她发了多个台湾旗帜,导致她的iMessage、Facebook Messenger和WhatsApp持续崩溃。🤣

在这篇文章中,我们将说明如何分析和跟踪这个远程iOS缺陷的根本原因。

 

崩溃

崩溃的设备是运行iOS 11.3(当时最新版本的iOS)的iPhone 7:

Device: iPhone 7, iPhone9,1 (US)
iOS: 11.3 (15E216)
Language: English, followed by Chinese
Region: United States
Jailbroken: No

以下是iMessenger(MobileSMS)提供的经过删减的崩溃报告。它是从设备(通过Settings -> Privacy, Analytics, Analytics Data)获取的:

{"app_name":"MobileSMS","timestamp":"2018-04-18 22:27:25.13 -0700","app_version":"5.0",  
"slice_uuid":"feac9bde-20a2-37c2-86e0-119fb8b9b650","adam_id":0,"build_version":"1.0",  
"bundleID":"com.apple.MobileSMS","share_with_app_devs":false,"is_first_party":true,  
"bug_type":"109","os_version":"iPhone OS 11.3  
 (15E216)","incident_id":"9EE5610B-7A0C-4558-895F-CF876DEB6B07","name":"MobileSMS"}  

Incident Identifier: 9EE5610B-7A0C-4558-895F-CF876DEB6B07
CrashReporter Key:   69340bb1126c092b97b9af069f4f6f037466ee0c
Hardware Model:      iPhone9,1
Process:             MobileSMS [10417]
Path:                /Applications/MobileSMS.app/MobileSMS
Identifier:          com.apple.MobileSMS
Version:             1.0 (5.0)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.apple.MobileSMS [2015]


Date/Time:           2018-04-18 22:27:24.9896 -0700
Launch Time:         2018-04-18 22:26:16.9044 -0700
OS Version:          iPhone OS 11.3 (15E216)
Baseband Version:    3.66.00
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread:  6

Filtered syslog:
None found

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib            0x00000001824b3e08 0x1824b3000 + 3592
1   libsystem_kernel.dylib            0x00000001824b3c80 0x1824b3000 + 3200
2   CoreFoundation                    0x00000001829f6e40 0x182909000 + 974400
3   CoreFoundation                    0x00000001829f4908 0x182909000 + 964872
4   CoreFoundation                    0x0000000182914da8 0x182909000 + 48552
5   GraphicsServices                  0x00000001848f7020 0x1848ec000 + 45088
6   UIKit                             0x000000018c8f578c 0x18c5d8000 + 3266444
7   MobileSMS                         0x0000000100e1867c 0x100df8000 + 132732
8   libdyld.dylib                     0x00000001823a5fc0 0x1823a5000 + 4032

....

Thread 6 name:  Dispatch queue: com.apple.ResponseKit
Thread 6 Crashed:
0   CoreFoundation                    0x0000000182922efc 0x182909000 + 106236
1   CoreEmoji                         0x00000001886b2354 0x1886a6000 + 50004
2   CoreEmoji                         0x00000001886b2354 0x1886a6000 + 50004
3   CoreEmoji                         0x00000001886b2c80 0x1886a6000 + 52352
4   CoreEmoji                         0x00000001886a8ebc 0x1886a6000 + 11964
5   ResponseKit                       0x00000001968754ac 0x19683d000 + 230572
6   ResponseKit                       0x0000000196872e9c 0x19683d000 + 220828
7   ResponseKit                       0x00000001968739b4 0x19683d000 + 223668
8   ResponseKit                       0x0000000196862e78 0x19683d000 + 155256
9   ResponseKit                       0x0000000196862c00 0x19683d000 + 154624
10  ResponseKit                       0x00000001968619f0 0x19683d000 + 150000
11  libdispatch.dylib                 0x0000000182340b24 0x18233f000 + 6948
12  libdispatch.dylib                 0x0000000182340ae4 0x18233f000 + 6884
13  libdispatch.dylib                 0x000000018234aa38 0x18233f000 + 47672
14  libdispatch.dylib                 0x000000018234b380 0x18233f000 + 50048
15  libdispatch.dylib                 0x000000018234bd4c 0x18233f000 + 52556
16  libdispatch.dylib                 0x000000018235411c 0x18233f000 + 86300
17  libsystem_pthread.dylib           0x0000000182673e70 0x182673000 + 3696
18  libsystem_pthread.dylib           0x0000000182673b08 0x182673000 + 2824


Thread 6 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x00000001add1ad38   x2: 0x0000000000000000   x3: 0x00000001ad364438
    x4: 0x0000000000000000   x5: 0x0000000000000001   x6: 0x0000000000000000   x7: 0x0000000000000000
    x8: 0x0000000000000000   x9: 0x00000001b4e15930  x10: 0x0000000ffffffff8  x11: 0x0000000000000040
   x12: 0xffffffffffffffff  x13: 0x0000000000000001  x14: 0x0000000000000000  x15: 0x00002d0000002d00
   x16: 0x0000000000000000  x17: 0x0000000000002d00  x18: 0x0000000000000000  x19: 0x0000000000000000
   x20: 0x00000001add1ad38  x21: 0x0000000000000000  x22: 0x0000000000000000  x23: 0x00000001c4864cc0
   x24: 0x00000001000404ef  x25: 0x0000000000050000  x26: 0x0000000103d059e4  x27: 0x0000000103d059e4
   x28: 0x0000000000000000   fp: 0x000000016f1a5b20   lr: 0x00000001886b2354
    sp: 0x000000016f1a5b00   pc: 0x0000000182922efc cpsr: 0x80000000

Binary Images:
0x100df8000 - 0x100e43fff MobileSMS arm64  <feac9bde20a237c286e0119fb8b9b650> /Applications/MobileSMS.app/MobileSMS

0x182909000 - 0x182c9ffff CoreFoundation arm64  <cf162b3ca2883453b2914300d4f19612> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
0x1886a6000 - 0x1886b7fff CoreEmoji arm64  <6d18237f09d23ce6aa6abb287d7aa515> /System/Library/PrivateFrameworks/CoreEmoji.framework/CoreEmoji
0x19683d000 - 0x19693ffff ResponseKit arm64  <4f7abc9a8f803cb2bff0172b8c69f13e> /System/Library/PrivateFrameworks/ResponseKit.framework/ResponseKit

我们将更详细地讨论这个问题,但是简单说就是在地址0x00000000000000处发生一个EXC_BAD_ACCESS (SIGSEGV) (Exception Subtype: KERN_INVALID_ADDRESS)。

这类崩溃通常表示空指针解引用(NULL-pointer dereference)。在这里,这个错误似乎是在iOS执行某种类型的表情处理时触发的(这与iMessenger接收到的台湾标志的触发相吻合)。

iOS系统崩溃报告中的其他相关信息包括:

  • 故障指令地址(0x0000000182922efc)
  • 崩溃前线程(#6)的调用堆栈
  • 相关的dylib(即调用堆栈中的那些)

 

崩溃分析

我们的目标是现在追查崩溃的原因。也就是说,为什么0x0000000182922efc上的指令取消引用一个空指针?

我们将从反转调用堆栈中出现的动态库(ResponseKit、CoreEmoji和CoreFoundation)开始。具体来说,我们将检查在调用堆栈中出现的这些dylib中的地址的代码。

因为我朋友的手机没有越狱,所以我们只能从设备中获取dylib二进制文件.我们必须从其他地方获取它们。事实证明,最简单的是来自于iOS 11.3的恢复映像。这类还原映像包含iOS系统二进制文件,例如我们要寻找的dylib。我们可以从ipsw.me获取iOS 11.3还原映像(iPhone_4.7_P3_11.0_11.3_15E216_Restore.ipsw)

下载这个文件后,我们就可以通过hdiutil命令挂载058-97716-127.dmg磁盘映像:

$ hdiutil attach iPhone_4.7_P3_11.0_11.3_15E216_Restore/058-97716-127.dmg expected CRC32 $BDE79F12 /dev/disk2 GUID_partition_scheme
/dev/disk2s1 EFI
/dev/disk2s2 Apple_APFS
/dev/disk3 EF57347C-0000-11AA-AA11-0030654 /dev/disk3s1 41504653-0000-11AA-AA11-0030654 /Volumes/Emet15E216.D10D101D20D201OS

由于我们要寻找的dylib被嵌入到dyld共享缓存(dyld_shared_cache_arm64)中,所以我们必须提取它们。

使用jtool,这是最直接的,只需指定要提取的dylib的名称(例如CoreEmoji),然后指定共享缓存的路径:

jtool -e "CoreEmoji" /Volumes/Emet15E216.D10D101D20D201OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64
Extracting /System/Library/PrivateFrameworks/CoreEmoji.framework/CoreEmoji at 0x6b4e000 into dyld_shared_cache_arm64.CoreEmoji

提取了以下dylib(在崩溃线程的调用堆栈中分别引用了这些dylib):

yld_shared_cache_arm64_CoreEmoji
version: 69.3.0
sha1: 20F6BECF7C76A3FEAFEB8D2321F593388A3CB9B6

dyld_shared_cache_arm64_CoreFoundation
version: 1452.23.0
sha1: AD3A226884BB3612694B9AB37DF18F42452D5139

dyld_shared_cache_arm64_ResponseKit
version 109.0.0
sha1: BDA7F1F329321C20539499EAF1C36693823CF60E

不幸的是,我们必须符号化这些dylib,因为他们的大多数符号都被“编辑”了:

$ nm dyld_shared_cache_arm64_ResponseKit
0000000194ce6f9c t <redacted>
0000000194ce701c t <redacted>
0000000194ce7090 t <redacted>
0000000194ce70c4 t <redacted>
0000000194ce71e4 t <redacted>
0000000194ce72e0 t <redacted>
0000000194ce72e8 t <redacted>
0000000194ce72f0 t <redacted>
0000000194ce735c t <redacted>
0000000194ce7444 t <redacted>
...

不过,首先让我们对提取的iOS dylib进行重新定位,以便它们的地址(在反汇编程序/反编译器中查看时)与崩溃报告中的地址相匹配。

要对每个提取的dylib进行重新定位,我们使用崩溃报告中的基地址(例如CoreEmoji的0x1886a6000)。在Hopper中,可以通过Modify -> Change File Base Address…来重新建立二进制文件的基地址:

一旦重设好了,我们就可以解决符号的问题了。

我不确定这样做的最佳方式,所以我只是利用了每个dylib的MacOS版本。具体来说,我将符号化的x64汇编(MacOS)与无符号的ARM64汇编(iOS)“匹配”。虽然有手动过程,但这工作得很好!

例如,以地址0x0000000196862c00(来自调用堆栈中的第9帧)为例。下面是方法的完整反编译(在IOS ResponseKit dylib中),其中包含地址0x00000196862c00:

//iOS ResponseKit
int <redacted>_194d0ab58(int arg0) {
    r25 = loc_19147d5e0(r2);
    r22 = loc_19147d5e0(r4);
    loc_19147d5e0(r5);
    r27 = *_RKMessageResponseDontOverrideLanguageID | r7;
    loc_19147d5e0(r6);
    loc_19147d5d8(arg0, 0x1b3e37900, r25, r3, r22, r5, &var_58, 0x0, r27);
    loc_19147d5e8();
    loc_19147d5dc(r26);
    loc_19147d5dc(r22);
    loc_19147d5dc(r25);
    loc_19147d5e0(var_58);
    loc_19147d5dc(r20);
    loc_19147d5dc(r21);
    r0 = loc_19147d7cc(r19);
    return r0;
}

如果我们反编译MacOS的ResponseKit(/System/Library/PrivateFrameworks/ResponseKit.framework),我们可以在RKMessageResponseManager responsesForMessageImp:maximumResponses:forConversationHistory:forContext:withLanguage:options:方法中找到“匹配的”x64反编译(请注意对RKMessageResponseDontOverrideLanguageID符号的引用):

* @class RKMessageResponseManager */
-(void *)responsesForMessageImp:(void *)arg2 maximumResponses:(unsigned long long)arg3 forConversationHistory:(void *)arg4 forContext:(void *)arg5 withLanguage:(void *)arg6 options:(unsigned long long)arg7 {
    r14 = [arg2 retain];
    r15 = [arg4 retain];
    var_38 = [arg5 retain];
    var_30 = arg6;
    rbx = *_RKMessageResponseDontOverrideLanguageID;
    r13 = [arg6 retain];
    rax = [self responsesForMessageWithLanguageDetectionImp:r14 maximumResponses:arg3 forConversationHistory:r15 forContext:arg5 withLanguage:&var_30 inputModes:0x0 options:rbx | arg7];
    [var_38 release];
    [r15 release];
    [r14 release];
    r14 = [rax retain];
    rbx = [var_30 retain];
    [r13 release];
    [rbx release];
    rax = [r14 autorelease];
    return rax;
}

现在我们知道iOS ResponseKit dylib中的int_194d0ab58方法实际上是RKMessageResponseManager responsesForMessageImp:maximumResponses:forConversationHistory:forContext:withLanguage:options:方法(注意对RKMessageResponseDontOverrideLanguageID符号的引用)。

一旦对dylib进行了重新基和(手动)符号化,就更容易理解这个bug了,因为方法名对它们的用途有相当的描述性。

我们将从分析崩溃线程(线程6)的调用堆栈中的地址开始,以揭示这个远程iOS bug的根本原因。

跳过对libDispatch.dylib的调用,从堆栈帧#10开始,并将每个地址映射到它所属的符号化方法(或块):

#10  ResponseKit   0x00000001968619f0
-[RKMessageResponseManager responsesForMessage:maximumResponses:forContext:withLanguage:options:completionBlock:]

#9 ResponseKit  0x0000000196862c00
-[RKMessageResponseManager responsesForMessageImp:maximumResponses:forConversationHistory:forContext:withLanguage:options:]

#8 ResponseKit  0x0000000196862e78
-[RKMessageResponseManager responsesForMessageWithLanguageDetectionImp:maximumResponses:forConversationHistory:forContext:withLanguage:inputModes:options:]:

#7 ResponseKit  0x00000001968739b4
 +[RKMessageClassifier messageClassification:withLanguageIdentifier:conversationTurns:]:

#6 ResponseKit  0x0000000196872e9c
-[NSLinguisticTagger languageOfRange:withAdditionalContext:withPreferredLanguages:]

#5 ResponseKit  0x00000001968754ac
+[RKUtilities removeEmoji:]

#4 CoreEmoji  0x00000001886a8ebc
CEMStringContainsEmoji

#3 CoreEmoji  0x00000001886b2c80
unnamed subroutine

#2 CoreEmoji  0x00000001886b2354
unnamed subroutine

#1 CoreEmoji  0x00000001886b2354
unnamed subroutine

#0 CoreFoundation  0x0000000182922efc
CFStringCompare + 0x38

好吧发生什么事了?看起来是这样的,当接收到消息时,ResponseKit会对消息进行分类,并且(如果某些分类是真的话)调用+[RKUtilities removeEmoji:]方法。这方法调用CoreEmoji动态库来执行实际的表情符号移除。

iOS为什么要删除表情符号?我们很快就会讲到的!

在调用一些未命名的子程序后,CoreEmoji调用CFStringCompare函数,该函数在地址0x0000000182922efc处的指令处崩溃。

地址0x0000000182922efc是故障指令的地址。它是调用堆栈(即帧#0)中的最终地址,也是崩溃报告“ARM线程状态”部分中的pc(程序计数器)寄存器中的最终地址。

CFStringCompare在0x0000000182922efc有什么指令?

0000000180dcaefc         ldr        x8, [x21]

ldr arm指令将“程序相对偏移或外部地址加载到寄存器”(arm)。在这里,它试图取消引用,并将值从x21寄存器加载到x8寄存器中。

查看崩溃报告中的“ARM线程状态”部分,可以看到x21寄存器在崩溃时是空的(0x00000000000000):

Thread 6 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x00000001add1ad38   x2: 0x0000000000000000   x3: 0x00000001ad364438
    x4: 0x0000000000000000   x5: 0x0000000000000001   x6: 0x0000000000000000   x7: 0x0000000000000000
    x8: 0x0000000000000000   x9: 0x00000001b4e15930  x10: 0x0000000ffffffff8  x11: 0x0000000000000040
   x12: 0xffffffffffffffff  x13: 0x0000000000000001  x14: 0x0000000000000000  x15: 0x00002d0000002d00
   x16: 0x0000000000000000  x17: 0x0000000000002d00  x18: 0x0000000000000000  x19: 0x0000000000000000
   x20: 0x00000001add1ad38  x21: 0x0000000000000000  x22: 0x0000000000000000  x23: 0x00000001c4864cc0
   x24: 0x00000001000404ef  x25: 0x0000000000050000  x26: 0x0000000103d059e4  x27: 0x0000000103d059e4
   x28: 0x0000000000000000   fp: 0x000000016f1a5b20   lr: 0x00000001886b2354
    sp: 0x000000016f1a5b00   pc: 0x0000000182922efc cpsr: 0x80000000

如果试图取消引用空地址(指针),这将与EXC_BAD_ACCESS(SIGSEGV)一起崩溃,这正是崩溃报告中给出的确切原因:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000

那么x21中的值应该是什么呢?很明显,一个有效地址。

但是,查看故障指令之前的指令(在CFStringCompare函数中)的arm64反汇编代码,我们可以看到它是传递给CFStringCompare的第一个参数。

_CFStringCompare:
0000000182922ec4         stp        x22, x21, [sp, #-0x30]!                     
0000000182922ec8         stp        x20, x19, [sp, #0x10]
0000000182922ecc         stp        x29, x30, [sp, #0x20]
0000000182922ed0         add        x29, sp, #0x20
0000000182922ed4         mov        x19, x2
0000000182922ed8         mov        x20, x1
0000000182922edc         mov        x21, x0
0000000182922ee0         tbz        x21, 0x3f, loc_182922efc        ;take this

loc_182922ee4:
0000000182922ee4         adrp       x8, #0x1b3519000                            
0000000182922ee8         ldr        x1, [x8, #0x308]                            
0000000182922eec         mov        x0, x21
0000000182922ef0         bl         0x181c1c900
0000000182922ef4         mov        x3, x0
0000000182922ef8         b          loc_182922fd0

loc_182922efc:
0000000182922efc         ldr        x8, [x21]                       ; b00m, we crash as x21 is NULL

也许反编译更能说明问题:

_CFStringCompare

r21 = theString1;
if ((r21 & 0xffffffff80000000) != 0x0) {
     r3 = loc_181c1c900(r21, *0x1b3519308);
}
else
{
     r8 = *r21; //b00m, we crash as this is NULL
}

反汇编0x0000000182922edc,我们可以看到第一个参数(在X0寄存器中传递)被移动到x21寄存器中:

mov        x21, x0

在0x0000000182922ee0(检测指针是否被“标记”)的测试之后,代码跳转到地址0x0000000182922efc,在那里取消对空x21寄存器的引用,从而导致崩溃。

寄存器x21上的检查(在此程序集指令中实现;TBZ x21、0x3f、loc_182922efc)是检查指针是否“标记”的检查。
标记指针是在iOS 7和MacOSX10.7中为64位架构引入的.带标记的指针是一种特殊的指针,它将数据直接存储到指针中,而不是进行内存分配。这具有明显的性能优势。blog.timac.org

CFStringCompare的函数定义是:

CFComparisonResult CFStringCompare(CFStringRef theString1, CFStringRef theString2, CFStringCompareFlags compareOptions);

第一个参数是一个命名为theString1的CFStringRef。由于崩溃是对第一个参数(X0,移动到x21)的取消引用,我们现在知道有些东西正在传入theString1参数的空值!

好了,我们已经找到了崩溃的直接原因:传递给CFStringCompare的空字符串。

让我们回顾一下调用堆栈跟踪,找出为什么会错误地传入这样一个空值!

回想一下,CFStringCompare是由地址为0x00000001886b22ec的CoreEmoji.dylib(dyld_shared_cache_arm64_CoreEmoji)中的一个未命名函数调用的。

由于提取的CoreEmoji二进制文件(来自dyld共享缓存)不是符号化的,因此只需从dylib的MacOS版本中删除这个子例程的分解代码就更简单了。

下面是这两个版本的反编译代码(为了说明MacOS和iOS版本中的代码是相同的):

//iOS (arm64)
int <redacted>_186b5a2ec {
    var_10 = r20;
    stack[-24] = r19;
    r31 = r31 + 0xffffffffffffffe0;
    saved_fp = r29;
    stack[-8] = r30;
    if (*qword_1b1c9baf8 != -0x1) {
            dispatch_once(0x1b37f3af8, 0x1add1a6f8);
    }
    r20 = loc_182938048();
    r19 = loc_1829387c8();
    loc_1829111e8(r20);
    if (*(int8_t *)byte_1b1c9bb00 != 0x0) {
            r0 = 0x0;
    }
    else {
            r0 = loc_182922ec4(r19, 0x1add1ad38, 0x0);
            if (r0 != 0x0) {
                    if (CPU_FLAGS & NE) {
                            r0 = 0x1;
                    }
            }
    }
    return r0;
}
//macOS (x64)
int sub_b9fe() {
    if (*qword_128e8 != -1)
    {
            dispatch_once(qword_128e8, ^ {/* block implemented at sub_ba72 */ } });
    }
    rbx = CFLocaleCopyCurrent();
    r14 = CFLocaleGetValue(rbx, **_kCFLocaleCountryCode);
    CFRelease(rbx);
    if (*(int8_t *)byte_128f0 != 0x0) {
            rax = 0x0;
    }
    else {
            rax = CFStringCompare(r14, @"CN", 0x0);
            rax = rax != 0x0 ? 0x1 : 0x0;
    }
    return rax;
}

在arm64反编译中,以下行表示对CFStringCompare的调用:

r0 = loc_182922ec4(r19, 0x1add1ad38, 0x0);

寄存器r19是第一个空参数(theString1),因此触发了崩溃。

再查找几行,我们可以看到r19被设置为调用loc_1829387c8()的返回值;

r19 = loc_1829387c8();

多亏了MacOS符号化的反编译,我们可以看到这是对CFLocaleGetValue()的调用。

Apple记录了以下功能:

CFTypeRef CFLocaleGetValue(CFLocaleRef locale, CFLocaleKey key);返回区域设置的键值对的给定键的对应值。

通过反编译,我们可以确定locale是来自CFLocaleCopyCurrent()的返回值,而键是_kCFLocaleCountryCode。

因此,源代码看起来可能如下所示:

CFLocaleRef locale = CFLocaleCopyCurrent();
CFStringRef countryCode = CFLocaleGetValue (locale, kCFLocaleCountryCode);

这段代码后面紧接着是对布尔标志的检查(iOS:byte_1b1c9bb00,MacOS:byte_128f0)。

坚持使用符号化的macOS dylib,我们可以找到这个值的交叉引用(x-ref),以确定它设置在哪里(sub_ba72):

void sub_ba72(void * _block) {
    rbx = CFPreferencesCopyValue(@"Country", **_kCFPreferencesAnyApplication, **_kCFPreferencesAnyUser, **_kCFPreferencesCurrentHost);
    if (rbx != 0x0) {
            r14 = CFEqual(rbx, @"CN") != 0x0 ? 0x1 : 0x0;
            CFRelease(rbx);
    }
    else {
            r14 = 0x0;
    }
    *(int8_t *)byte_128f0 = r14;
    return;
}

这段代码(sub_ba72)确定用户当前的‘国家’首选项。

如果不是中国(“cn”),则该标志设置为0x1(True)。如果国家是中国,或者CFPreferencesCopyValue()中止并返回NULL,则标志设置为0x0(False)。

我朋友手机的区域和语言没有设置为“cn”,所以这个标志(AFAIK)应该设置为0x1(真):

但是,由于代码用了else(反过来调用CFStringCompare(),它将指示该标志必须为0x0。

//check some flag ('CN')
if (*(int8_t *)byte_1b1c9bb00 != 0x0) {
    r0 = 0x0;
}

//we take this path
else {

  //call to CFStringCompare() that crashes
  r0 = loc_182922ec4(r19, 0x1add1ad38, 0x0);

  ... 

}

一种解释是,由于某些原因,对CFPreferencesCopyValue(@“Country”.)调用失败,会将标志设置为0x0。或者代码认为由于某种(未知的)原因,手机的区域设置为“cn”?

无论如何,调用CFStringCompare时,第一个参数(寄存器r19)设置为NULL:

//call CFStringCompare()
// first parameter is NULL, and thus crashes
// second parameter is @"CN"
r0 = loc_182922ec4(r19, 0x1add1ad38, 0x0);

请注意,只有在对CFLocaleGetValue()的调用失败(即返回NULL)时,r19寄存器才能为空。

一种解释是,对CFLocaleCopyCurrent的调用返回null,这反过来会导致CFLocaleGetValue也返回null(这反过来会将null传递给CFStringCompare(),从而导致崩溃)。

如果我们查看苹果代码中的其他地方,比如它们的CFStringCompareWithOptionsAndLocale函数,可以看到它们在这里检查CFLocaleCopyCurrent()的返回值:

locale = CFLocaleCopyCurrent();
langCode = ((NULL == locale) ? NULL : (const uint8_t *)_CFStrGetLanguageIdentifierForLocale(locale));

这意味着CFLocaleCopyCurrent()确实可能失败,并返回NULL(因此应该检查!)

不幸的是,我的理解只到这一点上了。也就是说,我不知道为什么以及在什么条件下:CFLocaleGetValue(CFLocaleCopyCurrent(),kCFLocaleNationalCode)可以返回NULL。但是它可以,而且这是不做检查的!因此,用NULL调用CFStringCompare(),应用程序就会崩溃!

苹果强调:

在某些情况下,如果设备的语言/区域设置不正确,即缺少区域代码,则可以返回NULL。若要触发此操作,必须将设备设置为不支持区域的无支持状态。

 

修复

两年多来,她的手机一直无法输入“台湾”,或者每当手机收到台湾旗帜表情符号时,她的手机就会被“远程攻击”,只不过是把这个地区从美国、中国大陆,再回到美国,一目了然。

我不能百分之百地确定为什么(或者如何修复它),但我猜它要么将‘Country’值设置为‘us’,所以现在boolan标志(在byte_1b1c9bb00处)被设置为0x1,这意味着CFStringCompare()从来没有被调用过,或者,对CFLocaleCopyCurrent()/CFLocaleGetValue()的调用不再返回null,这意味着一个有效的字符串被传递给了CFStringCompare()。

由于我不确定还有多少其他iOS用户受到影响,我也向苹果报告了这个问题。他们给它分配了CVE-2018-4290,并在iOS 11.4.1中对其进行了修复:

我还没有机会研究苹果的补丁,但我提出以下建议作为一个简单的解决方案:

为了避免这种崩溃,代码应该只检查调用CFLocaleGetValue()的结果,如果调用失败(即返回NULL),则跳过对CFStringCompare()的调用:

CFLocaleRef locale = CFLocaleCopyCurrent();
CFStringRef countryCode = CFLocaleGetValue (locale, kCFLocaleCountryCode);

//fix!
// make sure to check this!!
if(NULL != countryCode)
{
     CFStringCompare(countryCode, @"CN", 0x0);
}

//otherwise handle case where `countryCode` is NULL
else
{
  .... 
}

 

回顾

到目前为止,本文深入研究揭示并解释了一个(远程)iOS崩溃的技术原因。然而,仍然存在一个尚未回答但相当有趣的问题:“不管怎么说,这段代码到底想要完成什么?”

回顾:

  • 这起崩溃事件是由键入台湾或接收任何带有台湾旗帜(🇹🇼)的信息引发的。
  • 导致崩溃的方法(例如,RemoveEmoji)似乎与从接收到的消息中删除表情符号有关。
  • 故障指令之前的各种代码正在检查中国(“CN”)用户设备的语言/地区设置。
  • 传递给CFStringCompare(崩溃的函数)的第二个参数设置为(“cn”)。

这么多中国!嗯,那又有什么用呢!

答案可以在表情包网站上找到,上面写着:

此标志隐藏在设置为中国的iOS设备上的表情符号键盘上。中国的iPhone不会显示这个标志,而是会显示一个缺失的字符豆腐(☒)。

 

结论

在本文中,我们找到了远程iOS缺陷的原因。

尽管它的影响仅限于拒绝服务(空指针取消引用),但它为分析iOS代码提供了一个有趣的案例研究。

审核人:yiwang   编辑:边边

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多