屬性表文件(Plist)是一種文件形式，通常用于儲(chǔ)存用戶設(shè)置，也可以用于存儲(chǔ)捆綁的信息，該功能在舊式的Mac OS中是由資源分支提供的。由于Plist中存儲(chǔ)的數(shù)據(jù)是抽象的，其采用的文件格式可以不止一種。

macOS看起來(lái)非常有趣，尤其是屬性列表(plists)是存儲(chǔ)序列化對(duì)象的文件，在蘋(píng)果操作系統(tǒng)中很常見(jiàn)，類似于微軟Windows使用注冊(cè)表存儲(chǔ)配置數(shù)據(jù)。下面顯示了macOS應(yīng)用程序自動(dòng)器的基于xml的屬性列表示例。此屬性列表存儲(chǔ)應(yīng)用程序的版本信息以及其他有用數(shù)據(jù)如下所示：

屬性列表也可以采用二進(jìn)制形式，否則稱為bplist。顧名思義，這些是二進(jìn)制格式的屬性列表，這些屬性列表啟用了一些附加的對(duì)象類型和關(guān)系，包括字典。以下是一個(gè)示例bplist，盡管可以使用其他標(biāo)簽來(lái)支持該格式的其他版本，但是可以通過(guò)bplist00標(biāo)記來(lái)標(biāo)識(shí)該示例：

通過(guò)查看蘋(píng)果的開(kāi)源代碼，可以更好地理解bplist格式，我也發(fā)現(xiàn)這個(gè)參考非常有用。蘋(píng)果開(kāi)源代碼中定義的bplist格式如下：

二進(jìn)制plist格式

屬性列表為模糊測(cè)試提供了一個(gè)有趣的目標(biāo)，因?yàn)樗鼈兒苋菀妆徊僮飨到y(tǒng)的許多部分(包括更高特權(quán)的進(jìn)程)創(chuàng)建和使用。蘋(píng)果公司的開(kāi)源代碼使我能夠創(chuàng)建任意的bplist，并開(kāi)始模糊文件格式，同時(shí)使用內(nèi)置的macOS plutil命令行工具確保正確的語(yǔ)法。

我花了幾天時(shí)間來(lái)生成bplist來(lái)執(zhí)行該格式，并很快發(fā)現(xiàn)某些對(duì)象類型在被常見(jiàn)的macOS二進(jìn)制文件(例如Finder)以及更高特權(quán)的二進(jìn)制文件(包括Launch Services守護(hù)程序(LSD))進(jìn)行解析時(shí)會(huì)導(dǎo)致異常。系統(tǒng)崩潰日志表明Core Foundation框架中存在漏洞，但是，正如我們稍后將看到的，此漏洞存在于多個(gè)位置。Core Foundation(簡(jiǎn)稱CF)是一套Mac OS和iOS中的C語(yǔ)言API，由較低層的一些例程和封裝函數(shù)組成。Apple發(fā)布的最大的一個(gè)CF開(kāi)源項(xiàng)目叫CFLite，基于CFLite可以開(kāi)發(fā)跨Mac OS X，Linux和Windows平臺(tái)的應(yīng)用。另外一個(gè)第三方的開(kāi)源實(shí)現(xiàn)叫做OpenCFLite也有同樣的功能。大多數(shù)的Core Foundation例程的對(duì)象通常遵循這樣的命名規(guī)則，例如：CFDictionary開(kāi)頭的函數(shù)中會(huì)出現(xiàn)CFDictionaryRef，這些對(duì)象經(jīng)常被會(huì)手動(dòng)通過(guò)CFRetain和CFRelease來(lái)管理引用計(jì)數(shù)。在內(nèi)部，Core Foundation也會(huì)把一些基礎(chǔ)類型轉(zhuǎn)成Objective-C運(yùn)行時(shí)中可用的格式。

大多數(shù)生成的崩潰似乎是由Core Foundation解析bplist并隨后嘗試使用創(chuàng)建的對(duì)象的方式引起的。任何bplist的ObjectTable中有非字符串類型的對(duì)象(Date、Data、Bool等)都會(huì)在調(diào)用不存在的字符串相關(guān)選擇器時(shí)導(dǎo)致解析過(guò)程崩潰。其結(jié)果是，任何使用Core Foundation讀取屬性列表的進(jìn)程都可能因無(wú)法識(shí)別的選擇器異常而崩潰。下面是一個(gè)示例易受攻擊的代碼路徑：

使用以下C代碼以及與測(cè)試應(yīng)用程序位于同一目錄中的名為Info.plist的惡意屬性列表，可以輕松到達(dá)此位置：

崩潰分析

可以通過(guò)編程方式或通過(guò)將修改后的bplist放置在系統(tǒng)上自動(dòng)對(duì)其進(jìn)行分析的方式來(lái)為此漏洞生成崩潰，實(shí)際上，此漏洞的最初跡象之一是LSD在嘗試使用修改后的屬性列表注冊(cè)應(yīng)用程序時(shí)反復(fù)在我的系統(tǒng)上崩潰。

Objective-See有一篇很棒的博客文章，詳細(xì)介紹了通過(guò)LSD進(jìn)行的應(yīng)用程序注冊(cè)以及屬性列表的自動(dòng)解析。

下圖是控制臺(tái)輸出，顯示了在我的桌面上以合法的Info.plist身份修改后的bplist導(dǎo)致崩潰發(fā)生的頻率，還請(qǐng)注意用戶級(jí)和系統(tǒng)級(jí)進(jìn)程崩潰。

LSD崩潰

通過(guò)修改單個(gè)字節(jié)以將ASCII字符串對(duì)象(類型0x5X)更改為另一種對(duì)象類型，如DATE(類型0x33)，可以創(chuàng)建惡意的bplist。修改后的bplist示例如下：

這個(gè)很小的字節(jié)更改現(xiàn)在可以用于在macOS系統(tǒng)和iOS上造成嚴(yán)重破壞，盡管在此研究中未對(duì)該平臺(tái)進(jìn)行過(guò)測(cè)試。這種方法還會(huì)影響包括Spotlight在內(nèi)的多個(gè)數(shù)據(jù)庫(kù)，這些數(shù)據(jù)庫(kù)已被該惡意Info.plist攻擊，甚至在重新啟動(dòng)后也反復(fù)導(dǎo)致崩潰。

漏洞是如何發(fā)現(xiàn)的?

由于能夠輕松地重新創(chuàng)建崩潰，因此我深入研究了該漏洞的實(shí)際發(fā)生位置。跟蹤此漏洞的一種簡(jiǎn)單方法是查看崩潰進(jìn)程的堆棧跟蹤。以下是前面顯示的測(cè)試應(yīng)用程序的崩潰日志，該日志使用Core Foundation讀取了惡意屬性列表。

閱讀這篇文章以了解Core Foundation如何處理無(wú)法識(shí)別的選擇器異常并闡明堆棧跟蹤中的_CF_forwarding_prep_0會(huì)很有幫助。有了這些信息，我將之前的返回地址視為CFStringFind中的異常的可能來(lái)源，尤其是在調(diào)用_CFStringGetLength之后。下面的反匯編說(shuō)明了此調(diào)用：

CFString查找反匯編

我逐步完成了LLDB中的CFStringFind，直到調(diào)用_CFStringGetLength來(lái)檢查寄存器之前。從蘋(píng)果的_CFStringGetLength文檔中，我們知道第一個(gè)參數(shù)應(yīng)該是字符串，因此我們可以使用以下LLDB命令檢查RDI寄存器。

可以看到，第一個(gè)參數(shù)的對(duì)象類型不是字符串，而是惡意bplist中的_NSDate對(duì)象。下面的_CFStringGetLength的反編譯說(shuō)明了可能會(huì)出錯(cuò)的地方：

_CFStringGetLength反編譯

我們可以看到，在該函數(shù)的第一個(gè)參數(shù)上調(diào)用了長(zhǎng)度選擇器，我們知道該函數(shù)對(duì)于_NSDate對(duì)象將失敗，因?yàn)樗鼪](méi)有此選擇器，該理論也與崩潰日志相匹配。

如果我們繼續(xù)執(zhí)行這個(gè)函數(shù)，則會(huì)最終將在Objective-C異常處理的內(nèi)部遇到一個(gè)異常，這表明我們已找到這些崩潰的根本原因。

其他選擇器

繼續(xù)生成帶有非字符串對(duì)象的bplists，并且能夠從其他無(wú)法識(shí)別的選擇器在Core Foundation中生成其他崩潰。下面的崩潰日志是LSD在使用了一個(gè)惡意bplist和一個(gè)剩余的nscfdata對(duì)象后的崩潰日志：

此LSD崩潰的堆棧跟蹤如下：

注意，在Objective-C異常處理之前，崩潰的位置不是來(lái)自CFStringFind，而是實(shí)際上調(diào)用_CFStringGetCStringPtrInternal的CFStringFindWithOptionsAndLocale，最終由于調(diào)用錯(cuò)誤的選擇器_fastCStringContents而崩潰。這樣做的原因是，剩余的nscfdata類型實(shí)際上有一個(gè)長(zhǎng)度選擇器，所以它成功地通過(guò)了我們之前看到的第一個(gè)崩潰位置，并進(jìn)一步進(jìn)入Core Foundation，直到它調(diào)用另一個(gè)未識(shí)別的選擇器。

多個(gè)漏洞的發(fā)現(xiàn)

在此研究的早期，我使用plutil從惡意bplist生成崩潰，然后編寫(xiě)了自己的代碼以到達(dá)必要的代碼路徑。以下命令通過(guò)使用plutil作為目標(biāo)進(jìn)程和print plist標(biāo)志來(lái)設(shè)置一個(gè)LLDB會(huì)話，以開(kāi)始調(diào)試此崩潰，該標(biāo)志只會(huì)打印出人類可讀版本的屬性列表。

經(jīng)過(guò)幾次執(zhí)行之后，很明顯plutil實(shí)際上在其他位置崩潰，而不是在Core Foundation中崩潰。下面的輸出說(shuō)明了它試圖在__NSDate類型上調(diào)用長(zhǎng)度選擇器，該類型會(huì)導(dǎo)致無(wú)法識(shí)別的選擇器異常，但是此漏洞存在于plutil中，而不存在于Core Foundation中。

似乎在許多macOS應(yīng)用程序中存在類似的漏洞，這些漏洞假定bplists僅包含字符串對(duì)象類型。 LSD進(jìn)程崩潰的堆棧跟蹤如下所示：

如果我們使用GHIDRA來(lái)反匯編_LSPlistCompactString函數(shù)，則可以看到偏移量45或0x2D導(dǎo)致我們又對(duì)漏洞對(duì)象類型進(jìn)行了另一個(gè)長(zhǎng)度調(diào)用，大概是從我們現(xiàn)在在LSD數(shù)據(jù)庫(kù)中的惡意bplist調(diào)用的：

我們可以通過(guò)在_LSPlistCompactString上設(shè)置斷點(diǎn)并使用以下斷點(diǎn)命令打印第一個(gè)參數(shù)來(lái)驗(yàn)證這一點(diǎn)：

下面的輸出說(shuō)明LSD正在從惡意bplist獲取__NSDate對(duì)象：

這證實(shí)了我最初認(rèn)為的一個(gè)漏洞實(shí)際上是多個(gè)macOS二進(jìn)制文件中的許多漏洞，并且所有漏洞均源于bplist僅包含字符串對(duì)象的假設(shè)。

惡意影響

• 根級(jí)進(jìn)程可能會(huì)在普通用戶帳戶中崩潰，并且如果操作系統(tǒng)重新生成了根級(jí)進(jìn)程，則它們會(huì)反復(fù)崩潰(例如，LSD和MDS)。
• 系統(tǒng)不穩(wěn)定和拒絕服務(wù)特別是在Finder或其他與UI相關(guān)的進(jìn)程消耗了惡意bplist并使崩潰進(jìn)程需要崩潰0-click時(shí)發(fā)生，因?yàn)閼?yīng)用程序捆綁包，程序包等在寫(xiě)入磁盤(pán)時(shí)會(huì)自動(dòng)進(jìn)行處理。
• 有可能使普通用戶帳戶中與安全相關(guān)的進(jìn)程崩潰，從而刪除安全邊界(XProtect等)，盡管本文中并未對(duì)其進(jìn)行全面探討。
• 在自動(dòng)分析bplist的情況下有可能被遠(yuǎn)程利用。
• 受此漏洞影響的系統(tǒng)組件包括使用Core Foundation解析bplist的應(yīng)用程序，占很大的比例，在macOS 10.15.3上快速搜索了1000多個(gè)已安裝的二進(jìn)制文件，這些文件導(dǎo)入了實(shí)現(xiàn)此漏洞的函數(shù)。
• 許多應(yīng)用程序通過(guò)Core Foundation解析bplist數(shù)據(jù)，但也會(huì)在自己的代碼中錯(cuò)誤地訪問(wèn)生成的對(duì)象，這意味著漏洞發(fā)生的概率可能更大。

本文翻譯自：https://objective-see.com/blog/blog_0x5A.html

【責(zé)任編輯：趙寧寧 TEL：（010）68476606】