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

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

屬性列表也可以采用二進制形式，否則稱為bplist。顧名思義，這些是二進制格式的屬性列表，這些屬性列表啟用了一些附加的對象類型和關系，包括字典。以下是一個示例bplist，盡管可以使用其他標簽來支持該格式的其他版本，但是可以通過bplist00標記來標識該示例：

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

二進制plist格式

屬性列表為模糊測試提供了一個有趣的目標，因為它們很容易被操作系統(tǒng)的許多部分(包括更高特權的進程)創(chuàng)建和使用。蘋果公司的開源代碼使我能夠創(chuàng)建任意的bplist，并開始模糊文件格式，同時使用內置的macOS plutil命令行工具確保正確的語法。

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

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

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

崩潰分析

可以通過編程方式或通過將修改后的bplist放置在系統(tǒng)上自動對其進行分析的方式來為此漏洞生成崩潰，實際上，此漏洞的最初跡象之一是LSD在嘗試使用修改后的屬性列表注冊應用程序時反復在我的系統(tǒng)上崩潰。

Objective-See有一篇很棒的博客文章，詳細介紹了通過LSD進行的應用程序注冊以及屬性列表的自動解析。

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

LSD崩潰

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

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

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

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

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

CFString查找反匯編

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

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

_CFStringGetLength反編譯

我們可以看到，在該函數(shù)的第一個參數(shù)上調用了長度選擇器，我們知道該函數(shù)對于_NSDate對象將失敗，因為它沒有此選擇器，該理論也與崩潰日志相匹配。

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

其他選擇器

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

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

注意，在Objective-C異常處理之前，崩潰的位置不是來自CFStringFind，而是實際上調用_CFStringGetCStringPtrInternal的CFStringFindWithOptionsAndLocale，最終由于調用錯誤的選擇器_fastCStringContents而崩潰。這樣做的原因是，剩余的nscfdata類型實際上有一個長度選擇器，所以它成功地通過了我們之前看到的第一個崩潰位置，并進一步進入Core Foundation，直到它調用另一個未識別的選擇器。

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

在此研究的早期，我使用plutil從惡意bplist生成崩潰，然后編寫了自己的代碼以到達必要的代碼路徑。以下命令通過使用plutil作為目標進程和print plist標志來設置一個LLDB會話，以開始調試此崩潰，該標志只會打印出人類可讀版本的屬性列表。

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

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

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

我們可以通過在_LSPlistCompactString上設置斷點并使用以下斷點命令打印第一個參數(shù)來驗證這一點：

下面的輸出說明LSD正在從惡意bplist獲取__NSDate對象：

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

惡意影響

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

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

【責任編輯：趙寧寧 TEL：（010）68476606】