因为很少做过真实场景下的漏洞复现，深感自己知识的浅薄，恰巧团里的师傅发了个洞，让我看看怎么利用，因此顺便做一个简陋的分析吧。

漏洞编号为 CVE-2022-23613，现已公开了相关信息。该漏洞作为一个运行在 root 权限下的 RDP 服务，由于该漏洞最终能够导致任意代码执行，因此笔者打算以提权作为最终的利用目标。

若本文存在任何纰漏，请务必与我联系，我会尽快修正本文内容。

该项目的开源地址：https://github.com/neutrinolabs/xrdp

从已公开的 Patch 可以看出，它添加了一个对 size 变量的负数校验，似乎意味着整数溢出漏洞的存在，不妨跟踪一下该变量。

查找 self->header_size 的引用，可以发现该变量将与 self->trans_recv 的参数间接相关，而该函数类似于 read 的作用，将 self 相关的套接字中读取 to_read 个字符到 self->in_s->end 。

而该缓冲区来自于：

可以看见，该缓冲区会通过 g_malloc 创建在堆上，那么只要 to_read 的值超出了堆的原始大小，就有可能造成堆溢出了：

从调用点也可以看出，每次建立一个新的连接时都会为该连接创建一个大小为 0x2000 的输入缓冲区，并且接下来将会调用 trans_check_wait_objs ：

如果创建的类型不为 TRANS_TYPE_LISTENER ，那么该连接就会调用 self->trans_recv 将数据直接读进刚刚创建的输入缓冲区中，且由于它并没有校验 self->header_size 可能是负数的情况，因此可以令 to_read 通过负数减去一个正数溢出为一个极大的正数，从而导致堆溢出。

POC：

回顾一下刚刚的 trans_create 可以发现：

struct trans self 结构体与输入输出缓冲区同样位于堆内存中，并且它还初始化了函数指针，那么一个可行的利用点就是：通过堆溢出去覆盖 self->trans_recv 偏移处的值为一个类似 system 的函数来进行任意命令执行。

通过 IDA 搜索可以找到如下两个函数：

这两个命令分别是 execvp 和 execlp 的包装，函数实现如下：

因为 xrdp 服务是通过 socket 进行通信的，因此让其打开 “/bin/sh” 是不够的，想要让它能够完成任意命令执行，最好还是让它反弹一个 shell 出来比较合适，比方说：

这个格式就比较像 g_execlp3 的实现了对吗？看起来似乎相当可行，但是笔者在经过各种各样的尝试以后放弃了这个做法，因为精准的控制参数是一件极其困难的事情。

假设我们令 self->trans_recv 为 g_execlp3 ，那么我们就需要令 self 指向 “python3”，self->in_s->end 也是一个指向 “python3” 字符串的指针，以及 to_read 必须为一个指向参数的指针。

通过 IDA 搜索二进制程序中的字符串可以发现，唯一一个或许能用的字符串只有 "/bin/sh"，因此所有的参数字符串都需要我们一起放在 payload 中输入到内存里去才行。

但是有与常规的 CTF PWN 题不同的是，用户通过 socket 进行交互，泄露地址是一件比较麻烦的事情，大部分情况下甚至连回显都拿不到，更何况就算有办法拿到回显，泄露地址的参数也仍然需要控制，因此又要绕回到这个问题上，因此只好考虑如何在无地址的情况下完成利用。

self 是一个 struct trans ，为了触发 self->trans_recv ，我们需要先通过几个检查：

可以注意到，由于 self->status 的值是固定的，因此 self 为字符串时，只有前几个字符可以控制，不过看起来似乎还是够写至少八个字符的，因此第一个参数似乎可以稳定传参。

但是正如刚刚所说，另外两个参数的控制就显得有些麻烦了。

首先是 self->in_s->end，这意味着需要先覆盖 self->in_s 为 target_addr-end_offset：

也就是说，需要它是一个地址，而现在我们似乎没办法泄露随机的堆地址。

第二个是 to_read 函数，它通过两行代码计算得出：

控制 to_read 并不困难，假设我们需要它指向一个堆，由于堆地址总是小于 0x80000000，因此它是一个正数能够被保证，其次，self->header_size 能够被任意控制，因此控制其值本身是容易的，但是问题还是一样的，堆地址怎么来？

另外还有一个需要注意的点是，为了调用 self->trans_recv 需要先通过 self->trans_can_recv ，由于 self 结构体已经被覆盖，该函数是有一定可能调用失败的，该函数的实际实现如下：

由于我们完全不关心该函数的功能逻辑，笔者在构造 exp 时候打算令其直接恒真：

注意到程序有这么一个 gadget 可以利用，因此我们将该函数指针覆盖为该 gadget 时即可绕过检查。

您可能会注意到，每次初始化输入缓冲区和输出缓冲区时，都建立了 0x2000 大小的缓冲区，这个值并不小，那么如果多建立几个连接，是否就能够像堆喷那样完成利用呢？

可以看见，此处的 MAX_SHORT_LIVED_CONNECTIONS 较小，它只允许我们最多保持 16 个连接，生成的堆内存如下：

总共的堆内存大小为 0x6D000，考虑到堆一开始就有一部分被用于其他用途，笔者最终算出来的堆内存可用大小最多为 0x5b0b8，而堆的地址大概在 0x0300000~0x3500000

这个数值是笔者在调试过程中根据印象猜出来的，实际还是要以源代码为准，但笔者在这里想要表达的意思是，强行堆喷的成功率不高，粗算一下大概是 0.7112884521484375%(原神单抽一个五星的感觉)

但其实还不只是如此，因为强行堆喷需要布置的内容是参数+地址，大致结构如下：

而您需要保证的是：

如果您能够保证以上两点，args_str2_addr 由于可以通过偏移算出，因此几乎必中，to_read 参数也可以通过偏移算出，也能够保证几乎必中。

但您也发现了，这需要碰撞两次地址，对本就不太容易成功的条件更是雪上加霜。看起来似乎需要优化一下堆喷的思路才能够完成。

注：以下内容是笔者在尝试时的一种猜测，它没能成功，但笔者仍然写在这里，期望与各位师傅们探讨它的可行性。可能已经有过这样的技巧了，但作为一次学习记录，姑且写下吧。

因为一开始我们是将输入的结构作为一个整体进行地址碰撞，但似乎可以拆分一下来提高成功率。

结构一为：

结构二为：

也就是说，将字符串和指向字符串的地址拆分开，分别用两个结构去填充内存。

看起来似乎没有差别，但是由于 Glibc 管理的堆内存是一个线性结构，这意味着 args_str1 和 args_str1_addr 是可以有一个较为稳定的相对偏移的(这个偏移会浮动，但笔者认为浮动不大，只要字符串结构布置的足够密集，理论上会更容易命中一点)。

那么情况就会变成：如果 self->in_s 命中了 args_str1_addr-8 ，那么， args_str1_addr 为 args_str1+offset ，理论上也有不小的概率能够命中。

这么来看，似乎将本来需要碰撞两次的地址优化为了只 需要碰撞一次+一个中概率事件发生。

在 16 个连接的条件下，由于堆的大小较小，因此笔者没能成功，但是如果我们调大了这块内存，允许建立大约 100 个连接左右的情况下，堆的内存会骤增。笔者最后测试的结果大约是 10% 左右的碰撞命中率。

大致的 exp 如上，先将参数打入到堆内存的首部，然后再往之后的堆内存里去堆字符串的地址。最后在覆盖 self->in_s 时候用一个堆地址去撞。

在堆喷失败以后，笔者又试了一下其他的方法，最终认为，如果我们只需要在本机上进行提权，完全不需要这么麻烦去构造一个 execlp 的调用链。

首先，我们可以先写一个用于反弹 shell 的程序，用静态编译的方法将其编译到 ”/tmp/x“：

接下来我们令服务调用如下函数：

后两个参数是完全随意的，不管是什么，只要是合法参数都行，或者：

对于 execlp 的情况，由于服务中使用的实际上是 g_execlp3 ，因此我们需要保证第二和第三个参数是可解析的，只要它们是可解析的，那么为任意值都行。

而对于第二个情况，我们只需要令第二个参数为 0 即可，不过在该服务中，其实际实现如下：

self->in_s->end 为 0 将会失败，因为 args[args_len] 会引用错误的地址。因此最好的办法是找一个地方，让 self->in_s->end 能够指向 0 。

这似乎是有可能实现的，而且即便我们找不到任何指向 0 的指针，只要能有一片连续的地址保持如下结构就行了：

甚至于，直接尝试堆喷去撞那个将近 1% 的概率似乎也不是不能接受。

加之第一个参数是稳定控制的，尽管能写的字符数不多，但 ”/tmp/x“ 总共也不到八字节，绰绰有余。

这么一看，似乎对参数就有很多余裕了，只要参数符合调用规则，任意参数都可以。因此接下来就只剩下找到一个合适的地址作为参数去构造了。

最后的 EXP 结构大致如下：

这个 exp 可能是不通的，因为我选了用 execlp 去完成。主要是做到这一步之后，我感兴趣的部分已经全都完成了，所以差不多就停了，并且本文也已经写完了。

如果读者对 execvp 的方案感兴趣，也可以自行尝试一下。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)