launchd中消息隊列邏輯問題允許任意的mach message控制

首發看雪：[翻譯]launchd中消息隊列邏輯問題允許任意的mach message控制

來自yaren的寄語

我通常凌晨三點就起床，然後開始查收郵件，晨跑5英里達到我的辦公室，開始我一天的工作。人生沒有捷徑，我的座右銘是do more、know more、ne more。

上文對於陸奇的介紹，我們發現天才不是來自germ cell而是來自勤奮，只要努力我們足夠努力，我們一定能脫貧致富、成為陸奇一樣的人，突破職場天花板，致敬埃洛普成為微軟的高級木馬。

正文

2016年 八月二十日 星期六

Launchd升級為10.10版本。舊版本的（10.10之前）launchd是開源的，但是新的版本是封閉源、被剝離出來的單獨版本，所以甚至沒有function名字

然而...

新版本的launchd與xpc的事物緊密集成，這樣就給了我們一個良好的著力點去了解發生了什麼。此PoC中的所有function地址均基於OSnX 10.11.6裝載的launchd。

10002F3A1是引導埠上的處理程序 - 當接收到消息時，它從libxpc中調用xpc_pipe_try_receive，用來檢查接收的mach message的msgh_id：如果它是0x10000000，那麼這是一個xpc message，它會嘗試反序列化一個xpc對象；如果它是一個舊版本的MIG message，則xpc_pipe_try_receive將調用其第4個參數通過xpc_pipe_handle_mig來處理MIG消息。 10002ED33是launchd進程的舊版本的mig處理程序，它通過在100018ADE中註冊的幾個舊版本MIG子系統來進行檢驗（請注意，對10002E3EE的調用是指添加了舊版本的mig子系統到它們的數組。）（100018ADE還註冊了launchd 的XPC子系統（ipc系列）的處理程序）。

這是很好的，但有趣的是，實際上存在兩個調用路徑，一個是到xpc_demuxer（10002EE87）/ mig處理程序（10002ED33），而另一個是10002EC25。除了不存在對xpc_pipe_try_receive的調用，此function的邏輯與10002F3A1幾乎相同。稍稍回顧一下可以發現，當郵件由launchd接收時，此function不負責直接解析信息，而是用於「重新解析」「擱置」信息。

在某些情況下，當launchd無法立即服務請求時，它會將此請求排入調度隊列稍後再試，並且該請求最終將在此處結束。

此function（10002EC25）只直接接受xpc dictionary，而且它會通過檢查來發現該dictionary是否具有「mig-request」 key/value pair。如果有，則它會在xpc_dictionary之外讀取一個xpc_data_t並將其轉換成一個mach_msg_header_t，並將其通過xpc_pipe_handle_mig來傳遞到10002ED33（舊版本MIG處理程序）。

我找不到任何可以設置一個「mig-request」值的地方，所以我猜這是一個調試功能，又或者是因為意外留下？因為xpc是一個無模式的ipc機制，我們實際上可以只設置一個具有完全受控制的xpc_data_t有效負載的「mig-request」鍵（其值將被視為被launchd接收的有效的mach message）。唯一的先決條件是，我們要找出如何獲取一個我們發送到launchd的被擱置的XPC信息的方法——而似乎子系統 3的常式804（xpc_look_up_endpoint）有時將被擱置，這意味著如果我們修改這些請求中的一個，我們可以通過舊版本的MIG處理管道發送一個完全受控制的偽造的mach message。

這是一個驚人的野生的exploitation ——當偽造的mach message能夠傳遞到mach_msg_destroy來摧毀它的許可權和內存時，這個PoC會發送一個帶有OOL數據的信息，而這會導致讀取一個在0x414141410000的內核埠成為一個崩潰的嘗試（這個指針稍後也會被傳遞到vm_deallocate）。但是一個像這樣的bug可以使你做更多的事，例如擾亂launchd的埠的引用計數（因為我們可以在我們的信息中指定任意埠號，使其被看作是launchd的埠命名空間中的有效埠）。我們還可以取消映射任意頁面，並將無效的事物傳遞給傳統MIG處理程序。

就影響方面而言，launchd是系統上許可權最大的進程，你可以從任何進程涉及到它:-)

這個PoC會hook目標xpc請求的發送，並注入一個「mig-request」xpc_data_t —— 如果它不工作，嘗試關閉所有打開的瀏覽器，或使用乾淨的啟動重新開始。

譯者：赤（看雪ID:嗚呼哀哉）

校對：yaren

原文作者：ianbeer@google.com

微信公眾號：看雪iOS安全小組

我們的微博：http://weibo.com/pediyiosteam

我們的知乎：http://zhihu.com/people/pediyiosteam

加入我們：看雪iOS安全小組成員募集中：iOS安全小組成員招募中-『iOS安全』-看雪安全論壇

n[看雪iOS安全小組]置頂嚮導集合貼： ［新人請看］[看雪iOS安全小組]置頂嚮導集合貼-『iOS安全』-看雪安全論壇