2

I was reading through my infosec newsfeed and found this article:

http://www.theguardian.com/technology/2015/may/27/iphone-crash-bug-text-imessage-ios

It basically talks about a bug iOS has while parsing Arabic characters, specifically in notifications.

Reading a bit further into the subject I learned that the bug is exclusively executed when the notification is abbreviated with an ellipsis (...) and that ellipsis falls in the middle of the Arabic character.

Of course, right when it started to be a more interesting (and infosec oriented) reading, the author stops simply by saying "it causes the system to crash". Further searching hasn't lead me to any technical explanation either.

How is it possible that a simple operation like parsing a character can have such an important flaw?

  • there are many articles about this: http://www.reddit.com/r/apple/comments/37enow/about_the_latest_iphone_security_vulnerability/ – schroeder May 27 '15 at 17:18
  • 1
    its called a computing bug, it it happens because the sequence triggers an infinity loop with memory allocation. a great way to eat up all available memory. – LvB May 27 '15 at 17:24
  • Crashes OS X terminal too btw. – racec0ndition May 27 '15 at 21:07

2 Answers2

5

I just asked a similar question; mine was about how Apple will fix this though, not necessarily what the bug does that causes the phone to crash.

As @LvB suggested, it seems to be a bug in the SpringBoard notification text processing, where the program infinitely reads the Unicode string into memory, taking up all the available memory. Then, the SpringBoard throws a segmentation fault as it attempts to allocate memory that the kernel owns. It seems like a 'fast' restart because only the SpringBoard is restarted.

Apple hasn't released any details, but this is my output from Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips:

Hardware Model:      iPhone4,1
Process:             SpringBoard [395]
Path:                /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier:          com.apple.springboard
Version:             50 (1.0)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2015-05-27 13:59:33.737 -0400
Launch Time:         2015-05-27 13:36:16.197 -0400
OS Version:          iOS 8.3 (12F70)
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   CoreText                        0x28bf2264 0x28b54000 + 647780
1   CoreText                        0x28bc2e64 0x28b54000 + 454244
2   CoreText                        0x28bc37f8 0x28b54000 + 456696
3   CoreText                        0x28b8fb9c 0x28b54000 + 244636
4   CoreText                        0x28b91350 0x28b54000 + 250704
5   CoreText                        0x28b64716 0x28b54000 + 67350
6   CoreText                        0x28b644f6 0x28b54000 + 66806
7   CoreText                        0x28b64372 0x28b54000 + 66418
8   UIFoundation                    0x332561ca 0x331fb000 + 373194
9   UIFoundation                    0x332585ec 0x331fb000 + 382444
10  SpringBoard                     0x00320f9c 0x89000 + 2719644
11  SpringBoard                     0x00321084 0x89000 + 2719876
12  SpringBoard                     0x003212e0 0x89000 + 2720480
13  SpringBoard                     0x002bbb6c 0x89000 + 2304876
14  SpringBoard                     0x003020a8 0x89000 + 2592936
15  SpringBoard                     0x00301052 0x89000 + 2588754
16  SpringBoard                     0x0025d472 0x89000 + 1918066
17  SpringBoard                     0x0025d374 0x89000 + 1917812
18  SpringBoard                     0x0025d3e6 0x89000 + 1917926
19  SpringBoard                     0x0025d724 0x89000 + 1918756
20  SpringBoard                     0x0025d52a 0x89000 + 1918250
21  SpringBoard                     0x0025c2ba 0x89000 + 1913530
22  CoreFoundation                  0x2823b850 0x2812d000 + 1108048
23  CoreFoundation                  0x28165fe8 0x2812d000 + 233448
24  libdispatch.dylib               0x36831c80 0x36830000 + 7296
25  libdispatch.dylib               0x36831c6c 0x36830000 + 7276
26  libdispatch.dylib               0x3683d54e 0x36830000 + 54606
27  CoreFoundation                  0x281fc884 0x2812d000 + 850052
28  CoreFoundation                  0x281fafa4 0x2812d000 + 843684
29  CoreFoundation                  0x2814699c 0x2812d000 + 104860
30  CoreFoundation                  0x281467ae 0x2812d000 + 104366
31  GraphicsServices                0x2f91f1a4 0x2f916000 + 37284
32  UIKit                           0x2b8d1690 0x2b862000 + 456336
33  SpringBoard                     0x000908b4 0x89000 + 30900
34  libdyld.dylib                   0x3686faac 0x3686e000 + 6828

This is only through Thread 0 (the one that crashed) because the rest is not really important.

From the crash log you can see that the app that crashed was SpringBoard, and the cause is a SIGSEGV (segmentation fault). Then, the stack trace (ignore the system call on line 34) suggests that it was caused by:

33  SpringBoard                     0x000908b4 0x89000 + 30900

Take this with a grain of salt. Since I don't know what the source code is, and Apple obscured their crash logs with addresses instead of function names (it used to give function names), one can only guess by the stack trace and behavior of the crash.

It could also be an issue with how CoreText process the string before passing it to SpringBoard, we don't really know as we didn't design the internal apps in CoreServices.

Chris Cirefice
  • 1,460
  • 2
  • 13
  • 21
  • Frame 33 is the `main` function, since on OS X and iOS it's always the second frame from the bottom on the main thread (Thread 0.) – NobodyNada Jun 16 '15 at 01:01
0

From the many, many articles, it appears that the banner messaging system on stock iOS (non-jailbroken) has trouble processing the unicode and crashes. What are the exact internal issues? Apple hasn't explained that yet.

Jailbroken phones resort to 'safe mode' instead of a hard crash.

This is not a new bug.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • The links you suggest are for a similar bug that was supposedly fixed; this seems to be an issue with a different set of Unicode, but stems from the issue of text processing in general. – Chris Cirefice May 27 '15 at 17:52
  • @ChrisCirefice exactly - the old bug has been patched, but the OP was asking about how a parsing bug would work to crash an OS – schroeder May 27 '15 at 17:53