一个微软不认的0day

进内部交流群，领黑客资料

扫文末二维码

最近，我们向Microsoft报告了50多个EOP和信息泄漏漏洞。

但是微软不认为这是漏洞,因此，在这里，我们发布了两个非常稳定的信息泄漏漏洞，这些漏洞是我们上个月发现的，Microsoft拒绝修复它们。

漏洞1：usosvc.dll中的信息泄漏

服务中的堆地址泄漏错误usosvc，usosvc.dll!UsoSettingsUtil::GetSetting导致特权升级。

此错误的根本原因如下代码所示：

__int64 __fastcall UsoSettingsUtil::GetSetting(const unsigned __int16 *a1, VARTYPE a2, struct tagVARIANT *a3){    /*        ...      */    pvargDest.vt = 8;    pvargDest.llVal = (LONGLONG)v11;    v12 = VariantChangeType(&pvargDest, &pvargDest, 0, a2);    v7 = v12;    if ( v12 >= 0 )    {      v12 = VariantCopy(return_val, &pvargDest);      /*        ...      */}

a2是一个用户可以控制的int值，此代码段的功能将VARTYPE更改为您可以指定的类型，然后复制到并返回给调用方。

错误是如果调用者设置，一旦被调用，堆地址将被存储到其中。

因此，攻击者可以从return的成员中获取堆地址。

一旦攻击者获得了堆地址，他就可以绕过ALSR或进一步利用其他错误最终实现

pvargDestBSTRpvargDestreturn_vala2 = VT_EMPTYVariantChangeTypepvargDest.vtVTVARIANTEscalation of Privilege

要触发此错误，您应该首先 UxUpdateManager 从获取一个对象 usosvc，然后调用UxUpdateManager::GetCachedSettingValue

POC

编译并运行我提供的代码。您可以从中获取堆地址usosvc
要检查堆地址是否来自usosvc，您应该使用windbg附加到usosvc，在处设置断点VariantChangeType并集中于的VT成员pvargDest，检查它是否与返回的堆地址相同。
测试平台
Windows 10 2004 19041.450 img

漏洞2：usocoreworker.exe中的信息泄漏

这是另一个与前一个错误非常相似的错误。它位于中usocoreworker.exe!UsoSettingsUtil::GetSetting，您可以轻松地修改我们以前的POC来触发此错误。

微软的回应

提交后2周。我们得到了微软的回应。“Our engineering team provided this detail in their report: Reproduced, but since it only works in Medium IL this is a Moderate severity and should be addressed as v.Next (no repro on LowIL, AC)。”

这两个信息泄漏漏洞的时间表

2020年7月22日：找到并报告该错误。
2020年8月12日：MSRC答复说：“已复制，但由于它仅在中等IL中有效，因此严重性中等，应作为v.Next解决（对LowIL，AC不做复制）。”
2020年8月25日：发布。

讨论区

显然，这些漏洞是非常稳定的信息泄漏。

它打破了中型用户和系统服务之间的安全边界。

由于我们可以泄漏堆地址，因此我们可以使用它来破坏ASLR并与该服务中的另一个内存损坏错误进行链接以获得完整的EOP利用。

值得一提的是：此服务器中还有另一个内存损坏漏洞，因此我们可以将它们链接在一起以获得完整的EOP。

但是，有关此漏洞的故事也使我对Microsoft感到非常沮丧。

我猜微软已经放弃了Windows的修复工作，但是我仍然在愚蠢地寻找Windows Bug。

原文地址与下载地址：

https://github.com/hhlxf/USO_Info_Leak

零基础学黑客就那么回事