在Pwn2own 2017 比賽中，蘋果的macOS Sierra 和 Safari 10 成為被攻擊最多的目標之一。在此次比賽過程中，盡管有多支戰隊成功/半成功地完成了對macOS + Safari目標的攻破，然而360安全戰隊使用的漏洞數量最少，而且也是唯一一個通過內核漏洞實現沙盒逃逸和提權，并完全控制macOS操作系統內核的戰隊。在這篇技術分享中，我們將介紹我們所利用的macOS內核漏洞的原理和發現細節。
在Pwn2own 2017中，為了完全攻破macOS Sierra + Safari目標，徹底控制操作系統內核，360安全戰隊使用了兩個安全漏洞： 一個Safari遠程代碼執行漏洞（CVE-2017-2544）和一個macOS內核權限提升漏洞（CVE-2017-2545)。CVE-2017-2545是存在于macOS IOGraphics組件中的安全漏洞。
從互聯網上可循的源碼歷史來看，該漏洞最早在1992年移植自Joe Pasqua的代碼，因此這個漏洞已經在蘋果操作系統中存在了超過25年，幾乎影響蘋果電腦的所有歷史版本，同時這又是可以無視沙盒的限制，直接從沙盒中攻入內核的漏洞。
在我們3月比賽中獎漏洞負責任報告給蘋果公司后，蘋果已經在5月15日發布的macOS Sierra 10.12.5中修復了該漏洞。
尋找瀏覽器可訪問的內核驅動
和Windows系統一樣，Safari的瀏覽器沙盒限制了沙盒內進程可訪問的內核驅動，以減小內核攻擊面對沙盒逃逸攻擊的影響，因此我們進行的第一步研究就是尋找在瀏覽器沙盒內可訪問的內核驅動接口。
在macOS 上，系統根據下面兩個沙盒規則文件定義了Safari瀏覽器的權限范圍。
/System/ Library/Sandbox/Profiles/system.sb
/System/Library/Frameworks/WebKit.framework/Versions/A/Resources/com.apple.WebProcess.sb
我們進一步關注Safari瀏覽器能夠訪問的內核驅動種類。在system.sb文件中，我們發現這樣一個規則：
(allow iokit-open (iokit-registry-entry-class “IOFramebufferSharedUserClient”))
這個規則說明Safari瀏覽器可以打開IOFramebufferSharedUserClient這個驅動接口。IOFramebufferSharedUserClient是IOGraphic內核組件向用戶態提供的接口。IOGraphic是macOS上的核心基礎驅動，負責圖形圖像處理任務，10.12.4版本上對應的IOGraphic源碼包在：https://opensource.apple.com/source/IOGraphics/IOGraphics-514.10/ 。既然IOGraphic相關代碼是開源的，那么在下一步，我們就對IOGraphic進行了代碼審計。
攻擊面
IOFramebufferSharedUserClient 繼承于IOUserClient。用戶態可以通過匹配名“IOFramebuff”的IOService, 然后調用IOServiceOpen函數獲IOFramebufferSharedUserClient對象的端口。
在獲取一個IOUserClient對象port后，我們通過用戶態API IOConnectCallMethod可以觸發內核執行這個對象的 ::externalMethod接口； 通過用戶態API IOConnectMapMemory可以觸發內核執行這個對象的 ::clientMemoryForType接口; 通過用戶態API IOConnectSetNotificationPort可以觸發內核執行這個對象的 ::registerNotificationPort接口。
實際上IOFramebufferSharedUserClient提供的用戶態接口很少，其中函數IOFramebufferSharedUserClient::getNotificationSemaphore 引起了我們關注。在IOKit.framework中，實際上有個未導出的函數io_connect_get_notification_semaphore， 通過這個API，我們可以觸發內核執行相應IOUserClient對象的 ::getNotificationSemaphore接口。
漏洞：getNotificationSemaphore UAF
我們參考IOFramebufferSharedUserClient::getNotificationSemaphore的接口代碼
接口也很簡單，代碼如下：
IOReturn IOFramebufferSharedUserClient::getNotificationSemaphore(
UInt32 interruptType, semaphore_t * semaphore )
{
return (owner->getNotificationSemaphore(interruptType, semaphore));
}
由此可見， IOFramebufferSharedUserClient::getNotificationSemaphore直接調用的是它的所有者 （也就是IOFramebuffer實例）的getNotificationSemaphore接口。
OFramebuffer::getNotificationSemaphore代碼如下：
IOReturn IOFramebuffer::getNotificationSemaphore(
IOSelect interruptType, semaphore_t * semaphore )
{
kern_return_t kr;
semaphore_t sema;
if (interruptType != kIOFBVBLInterruptType)
return (kIOReturnUnsupported);
if (!haveVBLService)
return (kIOReturnNoResources);
if (MACH_PORT_NULL == vblSemaphore)
{
kr = semaphore_create(kernel_task, &sema, SYNC_POLICY_FIFO, 0);
if (kr == KERN_SUCCESS)
vblSemaphore = sema;
}
else
kr = KERN_SUCCESS;
if (kr == KERN_SUCCESS)
*semaphore = vblSemaphore;
return (kr);
}
通過上面的代碼大家可以看出來，vblSemaphore是一個全局對象成員。vblSemaphore初始值為0。這個函數第一次執行后，內核調用semaphore_create，創建一個信號量，將其賦予vblSemaphore。后面這個函數再次執行時就會直接返回vblSemaphore。
問題在于，用戶態調用io_connect_get_notification_semaphore獲取信號量后，可以銷毀該信號量。此時，內核中vblSemaphore仍指向一個已經銷毀釋放的信號量對象。
當用戶態繼續調用io_connect_get_notification_semaphore獲取vblSemaphore并使用該信號量時，就會觸發UAF（釋放后使用）的情況。
總結
IOUserClient框架提供了大量接口給用戶態程序。由于歷史原因，IOFramebufferSharedUserClient仍然保留一個罕見的接口。盡管用戶態的IOKit.framework中沒有導出相應的API，這個接口仍然可以調用，我們可以把內核中 IOFramebuffer::getNotificationSemaphore的UAF問題，轉化為內核地址信息泄漏和任意代碼執行，實現瀏覽器的沙盒逃逸和權限提升。
| 
