擊右上角關(guān)注我們，每天給您帶來(lái)最新最潮的科技資訊，讓您足不出戶也知道科技圈大事！
近期，大量有關(guān)微軟 Windows 10X 系統(tǒng)的相關(guān)信息被爆出。為了適應(yīng)可能會(huì)在未來(lái)幾年內(nèi)大量出現(xiàn)的雙屏以及可折疊屏幕產(chǎn)品，微軟推出了這款系統(tǒng)，它支持 UWP/Win32/PWA 應(yīng)用，并加入了 WonderBar 等相關(guān)功能。
在我看來(lái)，Windows 10X 很像是微軟在智能手機(jī)領(lǐng)域失敗后，在移動(dòng)平臺(tái)重新發(fā)起的一次進(jìn)攻。那么下面，我們就來(lái)盤點(diǎn)一下，從 Windows CE 出發(fā)，微軟曾經(jīng)在智能手機(jī)領(lǐng)域做過(guò)哪些努力。
Windows CE
1996 年，微軟面向嵌入式、移動(dòng)計(jì)算平臺(tái)等產(chǎn)品推出了 Windows CE 系統(tǒng)，并于 2008 年將其改名為 Windows Embedded Compact。這款系統(tǒng)由 Windows 95 經(jīng)過(guò)精簡(jiǎn)而來(lái)，是一款開(kāi)放的、可升級(jí)的 32 位嵌入式系統(tǒng)。
當(dāng)時(shí)「智能手機(jī)」這個(gè)概念還不成熟，反而 PDA （Personal Digital Assistant，又稱掌上電腦、個(gè)人數(shù)字助理）這個(gè)稱呼能夠讓更多人接受。與當(dāng)時(shí)市面上大多數(shù)手機(jī)采用的按鍵式操作不同，Windows CE 采用了觸摸屏進(jìn)行操作，但是電阻屏，并且經(jīng)常需要觸摸筆的設(shè)計(jì)讓這款系統(tǒng)的體驗(yàn)十分一般。
當(dāng)時(shí) Palm 操作系統(tǒng)已經(jīng)非常成功，幾乎成為了 PDA 產(chǎn)品的代名詞，Windows CE 并不順利。微軟在不斷改進(jìn) Windows CE 系統(tǒng)的同時(shí)，通過(guò)大量技術(shù)支持、直接資助以及頻繁的廠商合作，讓基于 Windows CE 的 PDA 產(chǎn)品在市場(chǎng)上站穩(wěn)了腳跟。
憑借著出色的開(kāi)放性以及可定制化的特點(diǎn)，Windows CE 不僅被用在了 PDA 產(chǎn)品當(dāng)中，也大量出現(xiàn)在例如 GPS 等設(shè)備，以及部分工業(yè)電腦當(dāng)中。
2009 年，魅族 M8 采用了基于 Windows CE 內(nèi)核的定制系統(tǒng) Mymobile。憑借出色的做工，在影音方面多年的積累，以及魅族為其打造的軟件市場(chǎng)，魅族 M8 一度被認(rèn)為是國(guó)產(chǎn)手機(jī)當(dāng)中最能夠與蘋果 iPhone 系列抗衡的手機(jī)產(chǎn)品，后來(lái)的事情應(yīng)該也不用我多說(shuō)了。
從 Windows Mobile 到 Winodws Phone
2000 年，微軟針對(duì)智能手機(jī)開(kāi)發(fā)了 Windows Mobile 系統(tǒng)。Windows Mobile 基于 Windows CE 內(nèi)核，設(shè)計(jì)初衷是「讓用戶擁有接近于桌面版本 Windows 系統(tǒng)的體驗(yàn)」，對(duì)系統(tǒng)的 UI 進(jìn)行了大幅度改進(jìn)。
2000 年 4 月，WIndows Mobile 第一個(gè)版本 Pocket PC2000 發(fā)布，當(dāng)時(shí)的智能手機(jī)手機(jī)仍然被看作是「口袋電腦」。隨著版本的迭代，Windows Mobile 逐漸與塞班、Palm 等系統(tǒng)形成了互相競(jìng)爭(zhēng)的趨勢(shì)，成為了智能手機(jī)行業(yè)內(nèi)的一個(gè)重要組成部分。
2007 年，微軟發(fā)布了 Windows Mobile 6.0，這款系統(tǒng)與 Windows Vista 系統(tǒng)類似。為了讓用戶擁有更接近于電腦的使用體驗(yàn)，微軟在這款系統(tǒng)當(dāng)中內(nèi)置了 IE、MSN 等自家軟件，并在 Windows Mobile 6.5 當(dāng)中加入了 Windows Marketplace 應(yīng)用市場(chǎng)。
隨著 iPhone 與 Android 系統(tǒng)的發(fā)展，Windows Mobile 無(wú)論是在界面還是在生態(tài)方面都逐漸開(kāi)始落后。微軟最終在 2010 年宣布停止對(duì) Windows Mobile 系統(tǒng)的所有技術(shù)支持，并于 2012 年關(guān)閉了 Windows Mobile Marketplace，失去了應(yīng)用下載功能的 Windows Mobile 無(wú)疑被判了死刑。
2010 年，微軟再次基于 Windows CE 內(nèi)核推出了 Windows Phone 系統(tǒng)，最初版本為 Windows Phone 7.0。這款系統(tǒng)不僅采用了名為 Metro 的界面，而且加入了 Xbox Live 游戲、Xbox Music 等微軟自家服務(wù)。
2011 年，微軟與諾基亞達(dá)成深度合作，共同研發(fā) Windows Phone 系統(tǒng)。從此，諾基亞的看家系列 Lumia 成為了 Windows Phone 以及后來(lái) Windows 10 Mobile 系統(tǒng)的旗艦平臺(tái)。
同年，微軟在 Windows Phone 7.5 當(dāng)中加入了簡(jiǎn)體中文支持。2012 年，隨著 Windows 8 系統(tǒng)的推出，微軟推出了 Windows Phone 8，棄用了之前的 Windows CE 內(nèi)核，換成與桌面端相同的 Windows NT 內(nèi)核，這讓所有 Windows Phone 7.5 用戶無(wú)法升級(jí)到 Windows 8 系統(tǒng)。
為了安慰老用戶的情緒，微軟推出了 Windows Phone 7.8 系統(tǒng)，沒(méi)有修改系統(tǒng)內(nèi)核，但是加入了部分 Windows 8 系統(tǒng)的新特性。
Lumia 在當(dāng)時(shí)的智能手機(jī)領(lǐng)域幾乎是外觀設(shè)計(jì)與拍照的高水平代表，依然無(wú)法挽救 Windows Phone 系統(tǒng)的頹勢(shì)。于是，Windows Phone 死于 8.1 版本。
Windows 10 Mobile
也許是微軟想要為新的系統(tǒng)帶來(lái)不一樣的命運(yùn)，隨著 Windows 10 系統(tǒng)的發(fā)布，微軟再一次換掉了移動(dòng)版系統(tǒng)的命名方式，推出了新系統(tǒng) Windows 10 Mobile。
已經(jīng)習(xí)慣于統(tǒng)一移動(dòng)平臺(tái)與桌面端體驗(yàn)的微軟不僅為 Windows 10 Mobile 帶來(lái)了全新的 Office 套件、Microsoft Edge 瀏覽器、與桌面版類似的系統(tǒng)更新和操作體驗(yàn)等特性，最關(guān)鍵的是加入了支持跨平臺(tái)運(yùn)行的 UWP（Universal Windows Platform）應(yīng)用。
根據(jù)微軟的說(shuō)法，UWP 應(yīng)用可以在 Windows 10、Windows 10 Mobile、HoloLens、Xbox 等基于 Windows 10 開(kāi)發(fā)的系統(tǒng)以及硬件平臺(tái)運(yùn)行，用戶可以獲得幾乎相同的體驗(yàn)。
為了推廣 Windows 10 Mobile 系統(tǒng)，微軟推出了 AOW 功能，允許搭載 Windows 10 Mobile 系統(tǒng)的手機(jī)直接安裝并運(yùn)行安卓系統(tǒng)的應(yīng)用，但這無(wú)異于飲鴆止渴。
決定一款系統(tǒng)是否成功的重要因素之一就是它的軟件生態(tài)如何。UWP 的軟件生態(tài)，大家打開(kāi) Windows 10 自帶的應(yīng)用商店就明白了?；蛘哒f(shuō)，有多少人根本不清楚它的存在，或者在最近一段時(shí)間沒(méi)有打開(kāi)過(guò)這個(gè)應(yīng)用商店？
Windows 10 Mobile 又一次失敗了。微軟在 2018 年宣布將停止針對(duì)這款系統(tǒng)的支持。經(jīng)過(guò)了多次延期，微軟在去年末停止了相關(guān)維護(hù)工作，也在后來(lái)關(guān)閉了 Windows 10 Mobile 的應(yīng)用商店。
Windows 10X
嚴(yán)格意義上來(lái)說(shuō)，Windows 10X 并不是為智能手機(jī)推出的操作系統(tǒng)。在該領(lǐng)域經(jīng)歷過(guò)多次失敗后，微軟也許不會(huì)再為智能手機(jī)推出新的系統(tǒng)。
但是，微軟一直以來(lái)致力于統(tǒng)一移動(dòng)端與桌面端的體驗(yàn)，本次押寶雙屏以及折疊屏產(chǎn)品，是否可以看作是微軟想要通過(guò)這些產(chǎn)品「重回」移動(dòng)端的一個(gè)寫照？或者說(shuō)，我們未來(lái)使用的移動(dòng)設(shè)備也許并不是智能手機(jī)。
根據(jù)目前的曝光內(nèi)容，微軟為 Windows 10X 系統(tǒng)準(zhǔn)備了大量定制化軟件，對(duì)許多界面進(jìn)行了重新繪制，并且著重提升了在手勢(shì)操作和語(yǔ)音等方面的體驗(yàn)。這些都可以看作是微軟在移動(dòng)平臺(tái)做出的努力。
Windows 10X 仍然默認(rèn)使用 UWP 應(yīng)用，也同樣可以運(yùn)行 Win32 以及 PWA 應(yīng)用，所以微軟想開(kāi)了？
無(wú)論 Windows 10X 是否能夠?yàn)檎郫B屏等新的產(chǎn)品類型帶來(lái)全新體驗(yàn)，還是它真的能夠讓微軟重回移動(dòng)產(chǎn)品的競(jìng)爭(zhēng)當(dāng)中，我都希望微軟能夠把這款系統(tǒng)做下去。畢竟，廠家之間的競(jìng)爭(zhēng)對(duì)于用戶來(lái)說(shuō)往往是有利的。
譯者：an0nym0u5
預(yù)估稿費(fèi)：200RMB
投稿方式：發(fā)送郵件至linwei#360.cn，或登陸網(wǎng)頁(yè)版在線投稿
一、前言
本文是內(nèi)核池溢出漏洞利用實(shí)戰(zhàn)之Windows 7篇的續(xù)集，我們將會(huì)在Windows 10系統(tǒng)中實(shí)現(xiàn)相同漏洞的利用，這將更加充滿挑戰(zhàn)因?yàn)槲④浌咀詮腤indows 8后采取了大量針對(duì)內(nèi)核池攻擊的防御措施。本文將更加深入地分析池相關(guān)的內(nèi)容，因此建議讀者先閱讀第一篇文章以作鋪墊。
1.1Windows 8系統(tǒng)的防護(hù)措施
Windows 8系統(tǒng)在池中采取了一系列安全改善措施，在這里我不作詳盡的列舉，不過(guò)我們可以關(guān)注這幾點(diǎn)：
a.真正安全的鏈接/斷開(kāi)鏈接
b.池索引驗(yàn)證：池索引覆蓋攻擊早已不是什么難事
c.不執(zhí)行非分頁(yè)池（No-Execute）：這是一種新式的非分頁(yè)池，可以說(shuō)是非分頁(yè)池的不執(zhí)行（NX）版，Windows默認(rèn)使用該類型的池而不是以往的非分頁(yè)池
d.SMEP：管理模式執(zhí)行保護(hù)
e.MIN_MAP_ADDR：內(nèi)存首地址0x1000是保留地址不能被分配，這可以防御空引用類漏洞的攻擊，這種防護(hù)已經(jīng)在Windows 7系統(tǒng)和64位的Vista系統(tǒng)中被攻破
f. NtQuerySystemInformation()缺陷：該缺陷在低完整性場(chǎng)景下（通常是瀏覽器沙箱）不再可以被利用
關(guān)于我們利用的配額進(jìn)程指針覆蓋漏洞說(shuō)明如下：
a.進(jìn)程指針目前通過(guò)cookie進(jìn)行了編碼：
1）.進(jìn)程指針在分配塊時(shí)進(jìn)行如下編碼：ExpPoolQuotaCookie 異或 ChunkAddress 異或 ProcessPointer
2）.塊空閑時(shí)進(jìn)程指針被用作canary并進(jìn)行如下編碼：ExpPoolQuotaCookie 異或 ChunkAddress
b.進(jìn)程指針被解碼后必須指向內(nèi)核空間否則會(huì)觸發(fā)異常檢測(cè)
如果你想了解詳盡的Windows 8關(guān)于這方面的緩解措施你可以讀一下這篇文章[1]（Windows 8系統(tǒng)堆內(nèi)部解析），另外該文作者Tarjei Mandt的另外一篇文章[2]（在windows 7系統(tǒng)中利用內(nèi)核池漏洞）提到的每一種攻擊手法都已經(jīng)得到了有效緩解。Windows 8系統(tǒng)中確實(shí)有通過(guò)控制RIP協(xié)議來(lái)獲取數(shù)據(jù)的漏洞可利用，但是這些漏洞在Windows 10系統(tǒng)中已經(jīng)通過(guò)在_OBJECT_HEADER中設(shè)置cookie的方式被修復(fù)。所以如果你想實(shí)現(xiàn)利用配額進(jìn)程指針覆蓋漏洞這種在Windows 7系統(tǒng)中使用過(guò)的攻擊手段，我們需要做到：
1）池Cookie（PoolCookie）：用它來(lái)正確編碼指針
2）溢出塊地址：也需要用它來(lái)編碼指針
3）已知地址內(nèi)核空間的任意數(shù)據(jù)：我們不僅要正確編碼指針，該指針指向內(nèi)核空間的同時(shí)還要指向我們偽造的一個(gè)結(jié)構(gòu)。
讓我們來(lái)嘗試一下吧！
二、獲取溢出塊指針
這一部分會(huì)很簡(jiǎn)短，前提是你還記得Windows 7系統(tǒng)下的基本利用方式池噴射技術(shù)，好了，是時(shí)候放大招了，我們將采用高級(jí)池噴射技術(shù)，該技術(shù)在這篇文章[3]（Windows內(nèi)核池噴射技術(shù)）中有闡述。運(yùn)用該文中的方法，我們可以預(yù)測(cè)任何可能的分配行為，當(dāng)然有了IOCTL的漏洞我們很容易就能知道輸入輸出管理器分配給系統(tǒng)緩沖區(qū)（SystemBuffer）的地址，由于系統(tǒng)緩沖區(qū)（SystemBuffer）是溢出的，我們溢出的塊在系統(tǒng)緩沖區(qū)（SystemBuffer）之后，因此我們可以得到塊地址。注意：我之前提過(guò)幾次，NtQuerySystemInformation漏洞在低完整性場(chǎng)景下不可利用，因此我們不能在低完整性層面拿到這個(gè)地址而是至少要在中等完整性層面。
三、獲取已知地址內(nèi)核空間的一些任意數(shù)據(jù)
有好幾種方式可以實(shí)現(xiàn)這個(gè)目標(biāo)，過(guò)去很長(zhǎng)時(shí)間，我都是利用池噴射技術(shù)并結(jié)合隨機(jī)IOCTL系統(tǒng)調(diào)用來(lái)往空閑的內(nèi)核空間存放數(shù)據(jù)，但這種方式并不可靠，從那以后我找到了更加可靠的方法。
CreatePrivateNamespace函數(shù)用于在分頁(yè)池中分配一個(gè)目錄對(duì)象，以下是該函數(shù)的定義：
HANDLE WINAPI CreatePrivateNamespace( _In_opt_ LPSECURITY_ATTRIBUTES lpPrivateNamespaceAttributes, _In_ LPVOID lpBoundaryDescriptor, _In_ LPCTSTR lpAliasPrefix);吸引人眼球的地方：
1）該函數(shù)返回一個(gè)句柄，這很正常因?yàn)檫@只是一個(gè)對(duì)象，不過(guò)這意味著我們可以在分頁(yè)池中獲取該目錄對(duì)象的地址。
2）該函數(shù)第二個(gè)參數(shù)是一個(gè)邊界描述符，它必須唯一，所以你可以利用CreateBoundaryDescriptor函數(shù)創(chuàng)建它：
a.函數(shù)定義
HANDLE WINAPI CreateBoundaryDescriptor( _In_ LPCTSTR Name, _In_ ULONG Flags);b.調(diào)用函數(shù)后賦值給一個(gè)變量，我們姑且起個(gè)HelloWorld!
關(guān)鍵點(diǎn)來(lái)了：邊界描述符名直接存儲(chǔ)在分頁(yè)池中的對(duì)象中，因此以下代碼
給出了分頁(yè)池塊：
《Hello World!》名存儲(chǔ)在對(duì)象地址+0x1A8偏移處，看起來(lái)對(duì)名字沒(méi)啥限制：
這里塊大小變成了之前的兩倍大，然而只是用來(lái)存儲(chǔ)邊界描述符名！順便提一點(diǎn)，既然該對(duì)象的大小可控，它就變成了讓分頁(yè)池噴射的強(qiáng)大工具。不管怎樣我們已經(jīng)能夠往內(nèi)核空間存放一些任意數(shù)據(jù)了，并且還可以利用NtQuerySystemInformation漏洞獲取它的地址。
四、獲取池Cookie
氣氛好像一下子緊張起來(lái)了。ExpPoolQuotaCookie是由驅(qū)動(dòng)產(chǎn)生的一個(gè)指針大小的8字節(jié)Cookie（64位系統(tǒng)下），它的熵足夠安全，我們沒(méi)有辦法猜測(cè)或者計(jì)算出它的值。乍看上去唯一獲取池cookie的方式是發(fā)現(xiàn)強(qiáng)大但很少見(jiàn)的任意讀取漏洞，于是我研究了ExpPoolQuotaCookie的利用過(guò)程。當(dāng)在進(jìn)程的配額管理過(guò)程中有池塊被利用時(shí)，池類型（PoolType）會(huì)設(shè)置配額位(Quota Bit)，并且有一個(gè)位于池頭后8個(gè)字節(jié)（64位系統(tǒng)）的編碼過(guò)的指針指向它：
但是在分配塊時(shí)問(wèn)題來(lái)了，塊被釋放后它看起來(lái)變了：
這里Process Billed值只是池Cookie和塊地址的異或，這個(gè)值用于canary來(lái)檢測(cè)池溢出攻擊，因此如果成功讀取到Process Billed值的話沒(méi)準(zhǔn)能得到池Cookie！假想有如下攻擊：
1）運(yùn)用池噴射技術(shù)分配一些可控的塊，塊地址已知并且隨時(shí)可釋放
2）先釋放其中一個(gè)塊
3）然后釋放它前面的塊
4）在之前的兩個(gè)塊地址處重新分配一個(gè)塊，這可以通過(guò)IOCTL漏洞實(shí)現(xiàn)，要確保系統(tǒng)緩沖區(qū)（SystemBuffer）在這里已經(jīng)分配
5）即使有了空閑空間和塊的重新分配，前一個(gè)池頭也不會(huì)重寫，這意味著池Cookie和塊地址的異或值仍然在塊數(shù)據(jù)中
這里可以假想一個(gè)返回的數(shù)據(jù)多于寫入數(shù)據(jù)的IOCTL漏洞：帶外讀取漏洞，用最小的一次帶外讀取就可以獲取到池Cookie，因此我們從剛開(kāi)始的任意讀取轉(zhuǎn)換成了帶外讀取來(lái)獲取池Cookie，這是一種更常見(jiàn)的手段，之所以這么說(shuō)是因?yàn)槲以谕瑯拥尿?qū)動(dòng)中發(fā)現(xiàn)了帶外讀取漏洞！
4.1關(guān)于CVE-2017-7441
以下是編號(hào)為0x22E1C0的IOCTL漏洞的偽代碼：
獲取我們的輸入后驅(qū)動(dòng)器在系統(tǒng)緩沖區(qū)中調(diào)用了RtlLookupElementGenericTableAvl函數(shù)，如果該函數(shù)執(zhí)行成功的話，它會(huì)在系統(tǒng)緩沖區(qū)中通過(guò)memcpy指令復(fù)制返回值，在復(fù)制前會(huì)檢查空間大小，因此這次memcpy不存在問(wèn)題，不過(guò)在計(jì)算驅(qū)動(dòng)器寫入多少字節(jié)時(shí)會(huì)出錯(cuò)，多返回2個(gè)多余的字節(jié)。如果想定位到有漏洞的代碼，函數(shù)RtlLookupElementGenericTableAvl必須執(zhí)行成功并且至少還要能夠控制它返回值的長(zhǎng)度，做到這一點(diǎn)的唯一方式是在系統(tǒng)緩沖區(qū)中寫入當(dāng)前進(jìn)程id，RtlLookupElementGenericTableAvl函數(shù)運(yùn)行正常且將路徑返回到當(dāng)前進(jìn)程的可執(zhí)行文件。或多或少我可以控制可執(zhí)行文件的路徑長(zhǎng)度，Windows下最大路徑長(zhǎng)度為255字節(jié)。為了獲取8字節(jié)的池Cookie需要用4個(gè)不同的可執(zhí)行文件（路徑長(zhǎng)度不同）創(chuàng)建4個(gè)不同進(jìn)程來(lái)觸發(fā)4次該漏洞。
五、結(jié)論
至此我們已經(jīng)完美實(shí)現(xiàn)了從Windows 7系統(tǒng)到Windows 10系統(tǒng)的內(nèi)核池漏洞利用過(guò)程，在Windows 10系統(tǒng)下利用池溢出漏洞比在windows 7下只差一個(gè)小漏洞的距離。池噴射技術(shù)和NtQuerySystemInformation漏洞提供給攻擊者太多內(nèi)核態(tài)的信息，使得攻擊者發(fā)動(dòng)針對(duì)池的攻擊依然可靠。你可以在github上找到我利用的代碼。
六、參考文獻(xiàn)
[1] https://media.blackhat.com/bh-us-12/Briefings/Valasek/BH_US_12_Valasek_Windows_8_Heap_Internals_Slides.pdf – Windows 8 Heap internals
[2] http://www.mista.nu/research/MANDT-kernelpool-PAPER.pdf – Kernel Pool Exploitation on Windows 7
[3] http://trackwatch.com/windows-kernel-pool-spraying/ – Pool Spraying article
[4] https://github.com/cbayet/Exploit-CVE-2017-6008 – Source code of the exploit