Glibc - 标签 - 有价值炮灰 https://evilpan.com/tags/glibc/ Glibc - 标签 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sat, 30 Jul 2022 12:40:00 +0800 IO_FILE 与高版本 glibc 中的漏洞利用技巧 https://evilpan.com/2022/07/30/glibc-exp-tricks/ Sat, 30 Jul 2022 12:40:00 +0800 evilpan https://evilpan.com/2022/07/30/glibc-exp-tricks/ Hacking glibc for fun and profit!

前言

在日常的二进制漏洞利用过程中，最终在获取到任意地址读写之都会面临一个问题: 要从哪里读，写到哪里去。对于信息泄露有很多方法，比如寻找一些数据结构在内存中残留的地址，可以是内部结构，也可以是用户定义的结构；相比而言，内存写原语的使用场景就相对有限了。因为在当今的系统安全纵深防护之下，代码和数据已经呈现了严格分离的趋势，可读可写可执行的历史遗留问题会逐渐退出历史舞台。更多的利用方法是关注代码重用(ROP)、可修改的函数指针、面向对象引入的多态调用等等。

具体的利用技巧和目标对象有直接联系，本文介绍的是基于 Glibc 的运行场景，也是当前很多 CTF 赛题所面临的场景。犹记得上古年代堆漏洞利用是那么单纯，先泄露 libc、然后 free_hook 写 system，然后 getshell。但随着 glibc 版本的更新，也逐渐引入了一些新的缓释措施，因此大家的目光就转向了其他的后利用链。其中 FILE 结构体虽然不是唯一的，但却是使用最多的，因此本文就来学习一下。

下文涉及源代码部分如无特殊说明均来自 glibc-2.35

FILE 101

我们平时往输入输出读写数据的时候，也许是直接使用 glibc 对系统调用的浅封装 open、read、write，但更多时候也使用 fopen、fread、printf 等，而后者大多是 POSIX 标准的 IO 函数。这些函数主要围绕 FILE 结构体而操作，由 fopen 返回，也就是常说的 _IO_FILE:

typedef struct _IO_FILE FILE;

该结构体的定义如下所示:

struct _IO_FILE
{
  int _flags;       /* High-order word is _IO_MAGIC; rest is flags. */

  /* The following pointers correspond to the C++ streambuf protocol. */
  char *_IO_read_ptr;   /* Current read pointer */
  char *_IO_read_end;   /* End of get area. */
  char *_IO_read_base;  /* Start of putback+get area. */
  char *_IO_write_base; /* Start of put area. */
  char *_IO_write_ptr;  /* Current put pointer. */
  char *_IO_write_end;  /* End of put area. */
  char *_IO_buf_base;   /* Start of reserve area. */
  char *_IO_buf_end;    /* End of reserve area. */

  /* The following fields are used to support backing up and undo. */
  char *_IO_save_base; /* Pointer to start of non-current get area. */
  char *_IO_backup_base;  /* Pointer to first valid character of backup area */
  char *_IO_save_end; /* Pointer to end of non-current get area. */

  struct _IO_marker *_markers;

  struct _IO_FILE *_chain;

  int _fileno;
  // ...
};

作为一个管理 IO 流缓冲的数据结构，需要保存当前用户写入的内存，包括已经读出和写入的大小和剩余数量等，这些位置使用指针表示；当然也包括系统调用所需的文件句柄 _fileno；另外 _flags 用于指定当前文件流的属性，比如是否可读可写等。

虽然我们平时也会使用 fopen 打开并读写文件，但更多的情况下并没有显式操作 FILE，而是使用了标准库中定义的 stdin、stdout 和 stderr 宏去进行读写标准输入输出。这些值其实也是 FILE 指针:

extern struct _IO_FILE_plus _IO_2_1_stdin_;

FILE *stdin = (FILE *) &_IO_2_1_stdin_;
FILE *stdout = (FILE *) &_IO_2_1_stdout_;
//...

以 stdin 为例，虽然其类型是 FILE *，但实际类型却是 _IO_2_1_stdin_ 的类型，即 _IO_FILE_plus:

struct _IO_FILE_plus
{
  FILE file;
  const struct _IO_jump_t *vtable;
};

该结构第一个元素包含的也是 FILE，因此可以进行强制类型转换。但末尾还多了个指针，一般这种模式常用于在 C 语言中实现面向对象(多态)调用，这个指针就作为虚函数表。该虚表的定义如下:

#define JUMP_FIELD(TYPE, NAME) TYPE NAME
struct _IO_jump_t
{
    JUMP_FIELD(size_t, __dummy);
    JUMP_FIELD(size_t, __dummy2);
    JUMP_FIELD(_IO_finish_t, __finish);
    JUMP_FIELD(_IO_overflow_t, __overflow);
    JUMP_FIELD(_IO_underflow_t, __underflow);
    JUMP_FIELD(_IO_underflow_t, __uflow);
    JUMP_FIELD(_IO_pbackfail_t, __pbackfail);
    /* showmany */
    JUMP_FIELD(_IO_xsputn_t, __xsputn);
    JUMP_FIELD(_IO_xsgetn_t, __xsgetn);
    JUMP_FIELD(_IO_seekoff_t, __seekoff);
    JUMP_FIELD(_IO_seekpos_t, __seekpos);
    JUMP_FIELD(_IO_setbuf_t, __setbuf);
    JUMP_FIELD(_IO_sync_t, __sync);
    JUMP_FIELD(_IO_doallocate_t, __doallocate);
    JUMP_FIELD(_IO_read_t, __read);
    JUMP_FIELD(_IO_write_t, __write);
    JUMP_FIELD(_IO_seek_t, __seek);
    JUMP_FIELD(_IO_close_t, __close);
    JUMP_FIELD(_IO_stat_t, __stat);
    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
    JUMP_FIELD(_IO_imbue_t, __imbue);
};

包含了针对文件 read、write、close、sync 等操作的函数指针，列举其中两个函数原型:

typedef ssize_t (*_IO_read_t) (FILE *, void *, ssize_t);
typedef ssize_t (*_IO_write_t) (FILE *, const void *, ssize_t);

上面介绍了 _IO_FILE 中的相关基础结构，接着看一下关于标准输入输出的定义，如下所示:

# define DEF_STDFILE(NAME, FD, CHAIN, FLAGS) \
  static _IO_lock_t _IO_stdfile_##FD##_lock = _IO_lock_initializer; \
  static struct _IO_wide_data _IO_wide_data_##FD \
    = { ._wide_vtable = &_IO_wfile_jumps }; \
  struct _IO_FILE_plus NAME \
    = {FILEBUF_LITERAL(CHAIN, FLAGS, FD, &_IO_wide_data_##FD), \
       &_IO_file_jumps};

DEF_STDFILE(_IO_2_1_stdin_, 0, 0, _IO_NO_WRITES);
DEF_STDFILE(_IO_2_1_stdout_, 1, &_IO_2_1_stdin_, _IO_NO_READS);
DEF_STDFILE(_IO_2_1_stderr_, 2, &_IO_2_1_stdout_, _IO_NO_READS+_IO_UNBUFFERED);

_IO_wide_data 是针对宽字符的虚函数表，这里先不关心，重点关注的是对 _IO_FILE_plus 结构体末尾虚函数表的定义，可以看到三者都被定义为了全局的 _IO_file_jumps:

#define libio_vtable __attribute__ ((section ("__libc_IO_vtables")))
#define JUMP_INIT(NAME, VALUE) VALUE
#define JUMP_INIT_DUMMY JUMP_INIT(dummy, 0), JUMP_INIT (dummy2, 0)

const struct _IO_jump_t _IO_file_jumps libio_vtable =
{
  JUMP_INIT_DUMMY,
  JUMP_INIT(finish, _IO_file_finish),
  JUMP_INIT(overflow, _IO_file_overflow),
  JUMP_INIT(underflow, _IO_file_underflow),
  JUMP_INIT(uflow, _IO_default_uflow),
  JUMP_INIT(pbackfail, _IO_default_pbackfail),
  JUMP_INIT(xsputn, _IO_file_xsputn),
  JUMP_INIT(xsgetn, _IO_file_xsgetn),
  JUMP_INIT(seekoff, _IO_new_file_seekoff),
  JUMP_INIT(seekpos, _IO_default_seekpos),
  JUMP_INIT(setbuf, _IO_new_file_setbuf),
  JUMP_INIT(sync, _IO_new_file_sync),
  JUMP_INIT(doallocate, _IO_file_doallocate),
  JUMP_INIT(read, _IO_file_read),
  JUMP_INIT(write, _IO_new_file_write),
  JUMP_INIT(seek, _IO_file_seek),
  JUMP_INIT(close, _IO_file_close),
  JUMP_INIT(stat, _IO_file_stat),
  JUMP_INIT(showmanyc, _IO_default_showmanyc),
  JUMP_INIT(imbue, _IO_default_imbue)
};
libc_hidden_data_def (_IO_file_jumps)

并且，该全局虚函数表在 ELF 中使用单独的段 __libc_IO_vtables 进行标识:

root@pwnlab:/pwn$ rabin2 -S /usr/lib/x86_64-linux-gnu/libc.so.6 | grep __libc
16  0x001baac0    0x1a01 0x001baac0    0x1a01 -r-x __libc_freeres_fn
27  0x00214910      0xe8 0x00215910      0xe8 -rw- __libc_subfreeres
28  0x002149f8       0x8 0x002159f8       0x8 -rw- __libc_atexit
29  0x00214a00     0xd68 0x00215a00     0xd68 -rw- __libc_IO_vtables

开头介绍 FILE 数据结构的时候，有一个字段还没介绍，即 struct _IO_FILE *_chain。从名字上也可以猜测这个字段用于实现链表结构。在上节介绍 stdin/out/err 定义的时候看到:

  • stdin->chain = 0
  • stdout->chain = &stdin
  • stderr->chain = &stdout

最后还定义了一个全局的头部 _IO_list_all:

struct _IO_FILE_plus *_IO_list_all = &_IO_2_1_stderr_;

从链表顺序可见，stdin 在链表尾部，stderr 在头部。实际在使用 fopen 打开新的文件流时，会经过一系列调用:

  • fopen/fopen64
  • _IO_new_fopen
  • __fopen_internal
  • _IO_new_file_init_internal
  • _IO_link_in

最终将新创建的 FILE 结构体插入上述链表的头部:

void _IO_link_in (struct _IO_FILE_plus *fp) {
    if ((fp->file._flags & _IO_LINKED) == 0) {
        fp->file._flags |= _IO_LINKED;
        fp->file._chain = (FILE *) _IO_list_all;
        _IO_list_all = fp;
    }
}

所以说全局的 _IO_list_all 维护了当前 IO 库所打开的所有文件流。这是为了方便所有文件流进行迭代，比如在程序退出前需要清空缓冲区并执行关闭文件等操作，这在后文漏洞利用的过程中也会提到。

上面其实简要介绍了 fopen 的流程，文件读写的过程其实也类似，先看读文件的 fread，其调用链路为:

  • fread
  • _IO_fread
  • _IO_sgetn
  • _IO_XSGETN

其中 _IO_XSGETN 是一个宏，其定义如下:

#define _IO_XSGETN(FP, DATA, N) JUMP2 (__xsgetn, FP, DATA, N)

#define JUMP0(FUNC, THIS) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS)
#define JUMP1(FUNC, THIS, X1) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1)
#define JUMP2(FUNC, THIS, X1, X2) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1, X2)
#define JUMP3(FUNC, THIS, X1,X2,X3) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1,X2, X3)

JUMPn 主要是跳转到 vtable 对应的字段获取动态函数地址，不同点主要在于参数个数。因此实际的文件读取流程都在 _IO_file_xsgetn 函数中，getn 表示从 fp 中读取 n 字节。具体实现代码太长就不复制了，可以简要概括如下:

  • 读取并不是直接读到给定的地址，而是先读到内部的缓存，由 _IO_buf_base 表示；
  • 如果内部缓存还没分配，使用 _IO_doallocbuf 进行分配，会从相同的虚表中查找对应的 __doallocate 方法并执行；
  • _IO_file_doallocate 内部会使用 malloc 分配缓存，默认大小是 8192；
  • _IO_buf_base 指向缓存头部，_IO_buf_end 指向尾部(=p+size)；
  • _IO_read_ptr 是缓存中有效数据的头部，_IO_read_end 是有效数据的尾部；
  • 如果循环读取的某一刻缓存中的有效数据为空，会触发虚表中的 _IO_file_underflow 调用，判断文件是否已经关闭，如果关闭了就退出读取返回 EOF 给用户，否则继续等待数据；
  • 最底层使用 vtable->read 即系统调用进行读取；

文件写入的流程也大同小异，使用虚表中的 xsputn 即 _IO_file_xsputn 方法进行写入。在新版本 glibc 中使用了新的实现 _IO_new_file_xsputn。和 fread 的差异主要在于内存分配的过程，实际是在触发 overflow 调用的时候进行内存分配的，下面是一个实际的栈回溯示例:

[#0] __GI___libc_malloc
[#1] __GI__IO_file_doallocate
[#2] __GI__IO_doallocbuf
[#3] _IO_new_file_overflow
[#4] _IO_new_file_xsputn
[#5] __GI__IO_fwrite
[#6] main

触发 overflow 表示内部缓存空间不足，此时会有几种不同的情况:

  1. 缓存还未申请(_IO_write_base == 0)，此时直接申请；
  2. 当前已经有缓存，并且正在读取(flags & _IO_CURRENTLY_PUTTING == 0)，此时需要调整对应的读写指针以腾出空间；
  3. 否则使用系统调用将数据写入到内核中，释放缓存空间压力；

还有一个值得一提的是 fclose，其大致操作如下:

  • 将 FILE 指针从全局单链表中删除(_IO_un_link)；
  • vtable->finish:
    • 清空内部缓存(vtable->flush)；
    • 关闭文件句柄(vtable->close)；
  • 释放内部缓存(free)；
  • 释放 FILE 结构体(free)；

至此，完成了对 stdio 生命周期的简单分析。

常见攻击

从前面的介绍可以看出，FILE 结构体之所以是一个常用的攻击目标，是因为其中虚函数表中存在大量的函数指针，并且在程序正常执行的生命周期会触发其中许多方法的查找和执行。加上 stdin、stdout、stderr 这些全局指针的存在，使得一旦可以劫持虚函数查找中的任意一级流程，就可以实现控制流劫持，从而进一步实现任意代码执行。

具体而言又有不同的细分，笔者只根据自己的经验去总结了一些常见攻击方法，若有疏漏可以在文末评论指出。

下文中会将 _IO_FILE_plus 和 FILE 统称为 FILE 结构。

通过前面的代码可知，内存中的 stdin 等全局变量存放着 _IO_2_1_stdin_ 等 FILE 结构体的地址，而且这个变量本身并不是 const 的，因此可以在运行中修改。攻击者一旦获取到内存任意读写的原语，就可以修改该变量，令其指向攻击者可控的内存中，并在内存里伪造一个 FILE 结构，从而让其中的 vtable 指向我们伪造的地址。最后在执行对应的 IO 操作时触发虚函数调用即可劫持 PC。

有一些细节需要注意，由于我们伪造了整个 FILE 结构，因此其中的每个字段都要保证不会影响正常运行。例如其中的最后一个字段 _IO_lock_t *_lock，需要是一个合法的指针，计数为 0 (表示未被占用)且可以修改，例如:

gef➤  p *stdin._lock
$1 = {
  lock = 0x0,
  cnt = 0x0,
  owner = 0x0
}

上节说到所有打开的 FILE 结构都会被存放到全局的 _IO_list_all 链表里，并通过 _chain 字段作为链表的 next 指针。在 libc 中有个函数 _IO_flush_all_lockp，主要作用是遍历上述链表，并对其中的每个文件执行刷新缓存的操作:

int _IO_flush_all_lockp (int do_lock) {
  int result = 0;
  FILE *fp;

  for (fp = (FILE *) _IO_list_all; fp != NULL; fp = fp->_chain)
    {
      run_fp = fp;
      if (do_lock)
    _IO_flockfile (fp);

      if (((fp->_mode <= 0 && fp->_IO_write_ptr > fp->_IO_write_base)
       || (_IO_vtable_offset (fp) == 0
           && fp->_mode > 0 && (fp->_wide_data->_IO_write_ptr
                    > fp->_wide_data->_IO_write_base))
       )
      && _IO_OVERFLOW (fp, EOF) == EOF)
    result = EOF;

      if (do_lock)
    _IO_funlockfile (fp);
      run_fp = NULL;
    }

  return result;
}

也就是说会调用 vtable->overflow 方法。这个特性的好处是我们可以通过伪造链表的方式进行多次任意调用，从而实现类似 ROP 的调用链构造。当然根据 && 的短路性质，所构造的 FILE 结构需要满足一些前置条件，一般是选择满足前者，即:

  • fp->_mode <= 0，且
  • fp->_IO_write_ptr > fp->_IO_write_base

因为后者相对复杂且可能会有一些副作用。

_IO_flush_all_lockp 在很多场景下都会被触发，比如:

  • main 函数返回时
  • 调用 exit 函数时
  • ……

因此可以在很多交互受限的场景下强行触发漏洞。下面是一个 main 函数退出时调用的栈回溯示例:

[#0] → _IO_flush_all_lockp(do_lock=0x0)
[#1] → _IO_cleanup()
[#2] → __run_exit_handlers(status=0x0, listp=<optimized out>, run_list_atexit=0x1, run_dtors=0x1)
[#3] → __GI_exit(status=0)
[#4] → __libc_start_call_main
[#5] → __libc_start_main_impl
[#6] → _start()

不管是虚表劫持还是 FSOP，在 glibc-2.24 之后都会遇到一个问题，即引入了针对虚表地址的额外判断:

# define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))
static inline const struct _IO_jump_t *
IO_validate_vtable (const struct _IO_jump_t *vtable)
{
  /* Fast path: The vtable pointer is within the __libc_IO_vtables
     section.  */
  uintptr_t section_length = __stop___libc_IO_vtables - __start___libc_IO_vtables;
  uintptr_t ptr = (uintptr_t) vtable;
  uintptr_t offset = ptr - (uintptr_t) __start___libc_IO_vtables;
  if (__glibc_unlikely (offset >= section_length))
    /* The vtable pointer is not in the expected section.  Use the
       slow path, which will terminate the process if necessary.  */
    _IO_vtable_check ();
  return vtable;
}

这是每次在查找虚表函数，即调用 JUMPn 时都会进行的检查，如果虚表地址不在对应段的范围，会额外进行一次 _IO_vtable_check 检查操作，如果不通过的话会直接 __libc_fatal 退出。

额外检查的目的是判断对应的 FILE 结构体是否在动态库的范围内，因为可能用户会跨动态库去调用外部方法。检查的实现主要如下:

void attribute_hidden
_IO_vtable_check (void)
{
  void (*flag) (void) = atomic_load_relaxed (&IO_accept_foreign_vtables);
  PTR_DEMANGLE (flag);
  if (flag == &_IO_vtable_check)
    return;

  {
    Dl_info di;
    struct link_map *l;
    if (!rtld_active ()
        || (_dl_addr (_IO_vtable_check, &di, &l, NULL) != 0
            && l->l_ns != LM_ID_BASE))
      return;
  }

  __libc_fatal ("Fatal error: glibc detected an invalid stdio handle\n");
}

其中 PTR_DEMANGLE 是 glibc 中引入的指针加密特性，目的就是为了提高攻击者修改指针劫持控制流的难度。

这个检查有效防止了修改虚函数表进行攻击的手法，因此业内又开始发掘其绕过方式或者其他的漏洞利用路径。

其中一种方法是不修改虚表，而是通过修改 FILE 结构体中的其他字段实现任意代码读写。其主要思路是通过这些字段扰乱 I/O 函数则正常执行流程。

对于 fwrite 而言，我们可以先将 fileno 改为 1(标准输出)，这样就可以在触发系统调用时将数据返回给我们，关键是如何设置系统调用的参数。在前面我们说过了，触发系统调用是通过虚表的 vtable->write 去实现的，所以我们主要看调用前的代码:

int
_IO_new_file_overflow (FILE *f, int ch) {
  /* If currently reading or no buffer allocated. */
  if ((f->_flags & _IO_CURRENTLY_PUTTING) == 0 || f->_IO_write_base == NULL) {
    // ...
  }
  if (ch == EOF)
    return _IO_do_write (f, f->_IO_write_base,
             f->_IO_write_ptr - f->_IO_write_base);
  if (f->_IO_write_ptr == f->_IO_buf_end ) /* Buffer is really full */
    if (_IO_do_flush (f) == EOF)
      return EOF;
  // ...
}

_io_do_write/flush 都会将 write_base 至 write_ptr 之间的数据写入到 fp 中，因此只要将其设置为目标地址区间，就可以实现对应地址的信息泄露。不过需要注意的是前面的两个判断需要绕过，以减少调整内部缓存区域引起的副作用。

简单来说，通过修改以下字段即可实现任意内存地址泄露:

  • _fileno 设为 1；
  • _flag &= ~_IO_NO_WRITES，清除掉读字段，只需要往目标文件写内容；
  • _flag |= _IO_CURRENTLY_PUTTING；添加该字段，绕过 overflow 的条件判断；
  • 设置 _IO_write_base 为想要泄露的起始地址，_IO_write_ptr 为结束地址；
  • 设置 _IO_read_end = _IO_write_base；

最后一项是为了在 do_write 的时候防止 seek 扰乱内存:

static size_t
new_do_write (FILE *fp, const char *data, size_t to_do) {
      size_t count;
  if (fp->_flags & _IO_IS_APPENDING)
    fp->_offset = _IO_pos_BAD;
  else if (fp->_IO_read_end != fp->_IO_write_base) {
        // seek
  }
  count = _IO_SYSWRITE (fp, data, to_do);
  // ...
}

同样的思路也可以用在 fread 中实现任意地址写:

size_t _IO_file_xsgetn (FILE *fp, void *data, size_t n) {
    // while (want > 0)
    have = fp->_IO_read_end - fp->_IO_read_ptr;
    if (want <= have) {
        // 直接拷贝缓存到目标地址
    } else {
        // ...
        if (fp->_IO_buf_base
          && want < (size_t) (fp->_IO_buf_end - fp->_IO_buf_base))
        {
          if (__underflow (fp) == EOF)
        break;

          continue;
        }
    }
}

int _IO_new_file_underflow (FILE *fp) {
    // ...
    if (fp->_flags & _IO_EOF_SEEN) return EOF;
    if (fp->_flags & _IO_NO_READS) return EOF;
    if (fp->_IO_read_ptr < fp->_IO_read_end)
        return *(unsigned char *) fp->_IO_read_ptr;
    // ...
    count = _IO_SYSREAD (fp, fp->_IO_buf_base,
            fp->_IO_buf_end - fp->_IO_buf_base);
}

如果我们想要从标准输入中写入，那么也只需要满足以下条件:

  • 设置 _fileno 为 0(标准输入)；
  • 设置 _flag &= ~_IO_NO_READS，绕过 underflow 中的判断；
  • 设置 buf_base 和 buf_end 分别为要写入的目标起始和结束地址，即手动指定缓存。注意写入的大小要小于该缓存大小，否则缓存会被刷到 data 中导致写入数据混乱；
  • 设置 read_base = read_ptr = NULL，这也是初次申请完缓存后 _IO_default_setbuf 设置的默认值；

其本质上是手动对缓存进行”创建“，这样在写入伪造缓存的时候也就写到了手动指定的缓存地址，实现任意地址写入。

除了修改数据指针，还有另外一种绕过 vtable check 的方法。既然 vtable 的作用是多态调用，那么肯定不会只有一种实现，事实上也如此。

例如，在 glibc 的代码中，除了 _IO_file_jumps 这个虚表，还有 _IO_str_jumps，属于另外一种 IO 类型 _IO_streambuf，包含在 _IO_strfile_ 结构中:

struct _IO_str_fields
{
  /* These members are preserved for ABI compatibility.  The glibc
     implementation always calls malloc/free for user buffers if
     _IO_USER_BUF or _IO_FLAGS2_USER_WBUF are not set.  */
  _IO_alloc_type _allocate_buffer_unused;
  _IO_free_type _free_buffer_unused;
};

struct _IO_streambuf
{
  FILE _f;
  const struct _IO_jump_t *vtable;
};

typedef struct _IO_strfile_
{
  struct _IO_streambuf _sbf;
  struct _IO_str_fields _s;
} _IO_strfile;

由于 _IO_str_jumps 这个虚表本来就在 glibc 中，因此是可以满足检查的:

const struct _IO_jump_t _IO_str_jumps libio_vtable =
{
  JUMP_INIT_DUMMY,
  JUMP_INIT(finish, _IO_str_finish),
  JUMP_INIT(overflow, _IO_str_overflow),
  JUMP_INIT(underflow, _IO_str_underflow),
  JUMP_INIT(uflow, _IO_default_uflow),
  JUMP_INIT(pbackfail, _IO_str_pbackfail),
  JUMP_INIT(xsputn, _IO_default_xsputn),
  JUMP_INIT(xsgetn, _IO_default_xsgetn),
  JUMP_INIT(seekoff, _IO_str_seekoff),
  JUMP_INIT(seekpos, _IO_default_seekpos),
  JUMP_INIT(setbuf, _IO_default_setbuf),
  JUMP_INIT(sync, _IO_default_sync),
  JUMP_INIT(doallocate, _IO_default_doallocate),
  JUMP_INIT(read, _IO_default_read),
  JUMP_INIT(write, _IO_default_write),
  JUMP_INIT(seek, _IO_default_seek),
  JUMP_INIT(close, _IO_default_close),
  JUMP_INIT(stat, _IO_default_stat),
  JUMP_INIT(showmanyc, _IO_default_showmanyc),
  JUMP_INIT(imbue, _IO_default_imbue)
};

如果我们可以修改 stdin/stdout 虚表的值为该虚表地址，那么就可以利用不同的实现方法去构造后续的任意地址读写原语，这对于使用 file_jumps 虚表条件难以满足时可以作为一种迂回的实现方案。这里细节就不展开了，可以参考网上其他的相关文章:

除了 str_jumps，其实在 glibc 中存在大量可选的虚表，在 GDB 中列举如下:

gef➤  info variables -t 'struct _IO_jump_t'
All defined variables with type matching regular expression "struct _IO_jump_t" :

File ./libio/fileops.c:
1481:   const struct _IO_jump_t _IO_file_jumps_maybe_mmap;
1457:   const struct _IO_jump_t _IO_file_jumps_mmap;
1432:   const struct _IO_jump_t __GI__IO_file_jumps;

File ./libio/iofopncook.c:
111:    static const struct _IO_jump_t _IO_cookie_jumps;

File ./libio/iopopen.c:
48:     static const struct _IO_jump_t _IO_proc_jumps;

File ./libio/iovsprintf.c:
38:     static const struct _IO_jump_t _IO_str_chk_jumps;

File ./libio/memstream.c:
36:     static const struct _IO_jump_t _IO_mem_jumps;

File ./libio/obprintf.c:
93:     const struct _IO_jump_t _IO_obstack_jumps;

File ./libio/strops.c:
353:    const struct _IO_jump_t _IO_str_jumps;

File ./libio/vsnprintf.c:
67:     const struct _IO_jump_t _IO_strn_jumps;

File ./libio/vswprintf.c:
66:     const struct _IO_jump_t _IO_wstrn_jumps;

File ./libio/wfileops.c:
1071:   const struct _IO_jump_t _IO_wfile_jumps_maybe_mmap;
1047:   const struct _IO_jump_t _IO_wfile_jumps_mmap;
1021:   const struct _IO_jump_t __GI__IO_wfile_jumps;

File ./libio/wmemstream.c:
37:     static const struct _IO_jump_t _IO_wmem_jumps;

File ./libio/wstrops.c:
362:    const struct _IO_jump_t _IO_wstr_jumps;

File ./stdio-common/vfprintf-internal.c:
2203:   static const struct _IO_jump_t _IO_helper_jumps;

比如在 HITCON 2017 : Ghost in The Heap Writeup 中基于 _IO_wstr_jumps 虚表中的 _IO_wstr_finish 方法实现利用。它们原理都是大同小异的，只有一些细节上的差异。

案例分析

本节来介绍几种比较常见的的后利用技巧，虽然大部分都是在堆漏洞的场景下提出的，但其中的一些思路同样也可以适用于其他的漏洞。

这是一种针对分配受限情况下堆漏洞的利用方法，源于 XCTF 2021 final，因为是 rekapig 战队出的题所以交了这个名字。主要限制是程序使用 calloc 分配内存，不走 tcache 从而无法使用 tcache stashing unlink attack 将布局好的 fake chunk 申请出来。

在这种情况下要想继续成功攻击，可以利用 FILE 结构体中的 I/O 缓存特性，在第一次读/写的时候如果缓存没有初始化，会使用 malloc 进行申请。在对虚表的选择上，该利用方法使用了 _IO_str_jumps 作为伪造 FILE 结构的虚表地址，因为 IO_str_overflow 函数内会连续调用 malloc 、memcpy、free，并且这三个函数的参数都可以由 FILE 结构内的数据来控制。

因此只要先在堆上布局好合适的数据，就可以在触发 overflow 调用 malloc、memcpy、free 三连时触发 __free_hook 劫持并触发任意代码劫持。原始题目中因为使用的是 largebin，因此最初是通过 largebin 攻击将堆地址写入到 _IO_list_all 中，最后通过 _IO_flush_all_lockp 去触发 IO_str_overflow 的调用。

具体堆风水细节这里就不展开了，感兴趣的同学可以参考文末的链接。

虽然现在大多数堆漏洞还是通过修改 __malloc_hook 或者 __free_hook 去实现代码执行，但在新版本的 glibc 中已经去除掉了(这两个符号依然存在，但是相应的 hook 不会被执行)。而且很多程序中还加上了 seccomp 的沙盒，要求只能执行 read/write/open，这又进一步限制了 ROP 执行 shellcode 的能力。

另外一个限制是 main 函数不会返回，且退出调用的不是 exit 而是 _exit，后者并不会触发 _IO_flush_all_lockp 调用。因此这种利用方法的主要思路是通过 __malloc_assert 触发 fflush(stderr)，从而调用 _IO_file_jumps.sync 方法。

虽然原文章中所说的将 sync 地址修改为指定地址同样有 vtable 校验的限制，但这个通过断言去触发 I/O 刷新的操作还是值得借鉴的。我们可以通过堆风水修改 top chunk 大小去主动触发这个断言从而劫持控制流。

该漏洞利用方法同样是为了解决在 glibc-2.34 之后取消 malloc/free hook 导致无法劫持控制流的问题。前面说过 FILE 的 vtable 需要在合法范围，也给出了一系列已有的虚函数表定义，但并没说虚函数表就一定要是其中某一个，实际上只要在对应 section 区间内就可以。

因此，该作者提出了微偏移的概念，在原有的虚函数表前后进行微小偏移，这样就可以在触发虚函数调用的时候执行该范围内的任意函数。为此选择了 _IO_cookie_jumps 这个虚函数表，并以及其中的 _IO_cookie_read、_IO_cookie_write 等函数为目标，因为其中存在函数指针的使用:

static ssize_t
_IO_cookie_read (FILE *fp, void *buf, ssize_t size)
{
  struct _IO_cookie_file *cfile = (struct _IO_cookie_file *) fp;
  cookie_read_function_t *read_cb = cfile->__io_functions.read;
#ifdef PTR_DEMANGLE
  PTR_DEMANGLE (read_cb);
#endif

  if (read_cb == NULL)
    return -1;

  return read_cb (cfile->__cookie, buf, size);
}

由于 FILE 结构是我们伪造的，因此大部分内容可控，关键是如何绕过 PTR_DEMANGLE 的指针加密保护，这在前面的章节中也说过。但世上没有绝对安全的系统，只不过是投入成本的问题罢了。通过查看对应代码的汇编可以发现，PTR_DEMANGEL 主要是将某个 TLS 段的值 ROR 移位后与原指针异或实现的加密。

gef➤  disassemble _IO_cookie_read
   0x00007ffff7e0d7b0 <+0>:     endbr64
   0x00007ffff7e0d7b4 <+4>:     mov    rax,QWORD PTR [rdi+0xe8]
   0x00007ffff7e0d7bb <+11>:    ror    rax,0x11
   0x00007ffff7e0d7bf <+15>:    xor    rax,QWORD PTR fs:0x30
   0x00007ffff7e0d7c8 <+24>:    test   rax,rax
   0x00007ffff7e0d7cb <+27>:    je     0x7ffff7e0d7d6 <_IO_cookie_read+38>
   0x00007ffff7e0d7cd <+29>:    mov    rdi,QWORD PTR [rdi+0xe0]
   0x00007ffff7e0d7d4 <+36>:    jmp    rax
   0x00007ffff7e0d7d6 <+38>:    mov    rax,0xffffffffffffffff
   0x00007ffff7e0d7dd <+45>:    ret

因此只要我们可以将这个值泄露出来或者修改为已知值，同样也能绕过指针加密。这样一来就可以伪造 read_cb 函数指针的值，从而实现任意代码执行的目的。

前面基于 vtable 劫持实现代码执行的方案都有一个重要缺点，那就是这些 vtable 都进行了加固，虽然可以使用微偏移的技巧，但指针加密(PTR_DEMANGLE) 始终是头顶上的一朵乌云。因为 TLS 段的值在远程利用时通常不可知，实际利用可能会需要涉及到地址爆破。

在此背景下，诸多赛棍师傅们有开发出了一系列新的利用方式。这个利用链公开的时间正好是本文撰写时，因此这一节实际上是笔者后来添加的。最早提出的利用方法应该是看雪论坛中的一篇文章 House of apple 一种新的glibc中IO攻击方，同一时间在 2022 年网鼎杯比赛的时候也出现了一道类似的题，作者赛后给出了 Writeup —— House of cat新型glibc中IO利用手法解析 && 第六届强网杯House of cat详解。这两个文章的利用思路都是类似的，即利用 IO wide table。

前面我们介绍 fread 读文件实现知道其最终会调用到 _IO_XSGETN，此时解析虚函数表的时候会触发校验 IO_validate_vtable:

fread
size_t _IO_fread (void *buf, size_t size, size_t count, FILE *fp)
size_t _IO_sgetn (FILE *fp, void *data, size_t n)
#define _IO_XSGETN(FP, DATA, N) JUMP2 (__xsgetn, FP, DATA, N)
#define JUMP2(FUNC, THIS, X1, X2) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1, X2)
# define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))

这个检查导致我们无法随意修改 vtable 的值实现 PC 控制，但注意到这个宏的附近还有这么一个宏:

#define WJUMP0(FUNC, THIS) (_IO_WIDE_JUMPS_FUNC(THIS)->FUNC) (THIS)
#define WJUMP1(FUNC, THIS, X1) (_IO_WIDE_JUMPS_FUNC(THIS)->FUNC) (THIS, X1)
#define WJUMP2(FUNC, THIS, X1, X2) (_IO_WIDE_JUMPS_FUNC(THIS)->FUNC) (THIS, X1, X2)

#define _IO_WIDE_JUMPS_FUNC(THIS) _IO_WIDE_JUMPS(THIS)

#define _IO_WIDE_JUMPS(THIS) \
  _IO_CAST_FIELD_ACCESS ((THIS), struct _IO_FILE, _wide_data)->_wide_vtable

_IO_WIDE_JUMPS_FUNC 与 _IO_JUMPS_FUNC 的一个最大不同点是前者不需要通过 IO_validate_vtable 的校验！这个特点是 House of Apple、House of Cat 以及后续的一系列利用链构造的基础。

以 House of Cat 为例，我们需要有下面的漏洞原语:

1.能够泄露堆地址和libc基址。 2.能够任意写一个可控地址。 3.能够触发 IO 流(FSOP或触发__malloc_assert，或者程序中存在puts等能进入IO链的函数），执行IO相关函数。

通过这些原语，我们可以修改任意数据，为可控地址，通常是修改 hook 或者 vtable 实现 PC 控制。在新版本的限制下，漏洞利用思路就比较明了了。首先我们可以将 stdio 的虚表修改为某个宽字符相关的虚表，比如 _IO_wfile_jumps，在微偏移的基础上还可以将其修改为该表的错位地址，使得调用能够进入特定的 IO 函数，比如 _IO_wfile_seekoff，该函数片段如下:

off64_t
_IO_wfile_seekoff (FILE *fp, off64_t offset, int dir, int mode)
{
  off64_t result;
  off64_t delta, new_offset;
  long int count;
 
  if (mode == 0)
    return do_ftell_wide (fp);
  int must_be_exact = ((fp->_wide_data->_IO_read_base
            == fp->_wide_data->_IO_read_end)
               && (fp->_wide_data->_IO_write_base
               == fp->_wide_data->_IO_write_ptr));
  bool was_writing = ((fp->_wide_data->_IO_write_ptr
               > fp->_wide_data->_IO_write_base)
              || _IO_in_put_mode (fp));
 
  if (was_writing && _IO_switch_to_wget_mode (fp))
    return WEOF;
// ......
}

从而间接进入 _IO_switch_to_wget_mode，触发 _IO_WOVERFLOW 的查表操作，最终读取 _wide_vtable 中的数据转换成函数指针并调用，实现 PC 控制！

#define _IO_WOVERFLOW(FP, CH) WJUMP1 (__overflow, FP, CH)
int _IO_switch_to_wget_mode (FILE *fp)
{
  if (fp->_wide_data->_IO_write_ptr > fp->_wide_data->_IO_write_base)
    if ((wint_t)_IO_WOVERFLOW (fp, WEOF) == WEOF)
      return EOF;
  // ...
}

这其中需要关注的是如何通过内存布局去操作控制流转移过程中的一些跳转判断，比如 _IO_wfile_seekoff 中的 was_writing，_IO_switch_to_wget_mode 中的 _IO_write_ptr > _IO_write_base 等。这只是其中一条利用链路，实际上根据这个思路可以挖掘出更多利用链，但个人认为每个利用链都起一个 House 也大可不必，而且这种利用方式可以通过直接给 WJUMP 也加上虚表校验来防御，这就看有没有好事者给 glibc 提 patch 了。

最后一种技巧和 FILE 结构没什么关系，但我觉得很有趣，所以也介绍一下，让大家感受一下世界的参差。这种技巧依赖于 Largebin attack 可以往任一地址写堆地址的能力，主的目标是伪造 ld.so 中的 rtld_global 结构体。我们知道 ELF 中有也有 ctor 和 dtor，主要是可以让动态链接的程序在加载初期和结束前运行指定代码，这种攻击方法就是瞄准了程序结束后执行的 .finit_array 数组，相关代码片段如下:

if (l->l_info[DT_FINI_ARRAY] != NULL)
{
    ElfW(Addr) *array =
    (ElfW(Addr) *) (l->l_addr
            + l->l_info[DT_FINI_ARRAY]->d_un.d_ptr);
    unsigned int i = (l->l_info[DT_FINI_ARRAYSZ]->d_un.d_val
            / sizeof (ElfW(Addr)));
    while (i-- > 0)
    ((fini_t) array[i]) ();
}

如果能够伪造对应的 FINIT_ARRAY，同样也能实现任意代码执行。当然实现上要解决 ld.so 与 libc.so 之间的 ASLR 偏移问题，据说可以通过爆破第二低字节解决，不过笔者只是出于叶公好龙的口嗨状态，还没有实际尝试过，等测试后再回来补充吧。

小结

由于 glibc 中的代码较多，也就给攻击者提供了许多藏污纳垢之地，仅仅是 I/O 这块就包含了各种不同的漏洞利用姿势。但回头来看，IO_FILE 的战场最初是围绕函数指针(虚表)展开的，且随着不断加固，为了绕过又不得不引入复杂的内存布局。放眼未来的话其实可以打开思路，不仅局限于某个特定结构，甚至不必局限于 libc，文末的 Bnana 就是一个很好的示例。相信随着网络安全行业的发展，会涌现出更多的新人才和新思路，当然 CTF 比赛也会更卷一些了 :)

参考文章

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/07/30/glibc-exp-tricks/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> ptmalloc cheatsheet https://evilpan.com/2022/07/17/ptmalloc-notes/ Sun, 17 Jul 2022 12:40:00 +0800 evilpan https://evilpan.com/2022/07/17/ptmalloc-notes/ 最近公司被要求参加某网络安全比赛，所以借此机会又重新阅读了 glibc malloc 的最新代码，发现了许多之前未曾深究的细节。故整理成此文，也算是对从前文章的补充了。

前言

几年前已经写过了一篇 ptmalloc 与 glibc 堆漏洞利用，但是一来当时学习仓促，很多内容自己也只是一知半解；二来已经时过境迁，当时的 glibc 距今也更新了不少，而且当时理解的内容太久没有复习又全部还给老师了。因此，本文又重新将其整理一遍，当然不再介绍基础概念，只记录重点以备考试时快速查阅。

数据结构

首先在 arena 中实际上只分成两个 BIN，分别是 fastbinsY 和 bins。而 bins 中包含了常用的 unsorted bin、small bin、large bin，统称为 regular bins。

在 regular bins 数组中，bin_at(0) 不存在，bin_at(1) 为 unsorted bin，小于 MIN_LARGE_SIZE 的为 small bin，大于等于则为 large bin。对于 32/64 位系统来说，该值分别为 0x200/0x400:

#define NBINS             128
#define NSMALLBINS         64
#define SMALLBIN_WIDTH MALLOC_ALIGNMENT // -> 0x08/0x10
#define SMALLBIN_CORRECTION (MALLOC_ALIGNMENT > 2 * SIZE_SZ) // -> 0
#define MIN_LARGE_SIZE ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH) // -> 0x200/0x400

上面说到 unsorted bin 对应 bin_at(1)，但注意不要与 bins[1] 弄混，其实现如下:

#define unsorted_chunks(M)          (bin_at (M, 1))
#define bin_at(m, i) \
  (mbinptr) (((char *) &((m)->bins[((i) - 1) * 2]))			      \
             - offsetof (struct malloc_chunk, fd))

可以看到 bin_at 对应的 bins 索引是 (i-1) * 2，而且取到地址之后还回退一个偏移。乍看起来很奇怪，但实际上这是写代码的一个小优化，返回的地址会转换为 chunk 指针，但实际上并不是一个正常的块，而只是将其当做一个空闲的头部，只使用其中的 fd/bk 字段，分别指向不同的 bin。假设返回的指针是 P，则有:

P->fd = m->bins[(i-1) * 2];
P->bk = m->bins[((i-1) * 2) + 1];

也就是说，bin_at(i) 返回的 chunk， 似 chunk 又非 chunk，本身在 bins 中占两个坑，虽然不能当做真的 chunk 返回给用户使用，但是却正好当做双链表的固定表头。

实际测试一下可能更清楚一些，在 unsorted bin 为空时，有以下属性:

pwndbg> p *main_arena.bins[0]
$1 = {
  mchunk_prev_size = 94692393318320,
  mchunk_size = 0,
  fd = 0x7f5bfe942cc0 <main_arena+96>,
  bk = 0x7f5bfe942cc0 <main_arena+96>,
  fd_nextsize = 0x7f5bfe942cd0 <main_arena+112>,
  bk_nextsize = 0x7f5bfe942cd0 <main_arena+112>
}

pwndbg> distance main_arena.bins[0] &main_arena.bins[0]
0x7f5bfe942cc0->0x7f5bfe942cd0 is 0x10 bytes (0x2 words)

bin 中的唯一一个 chunk，其 fd 和 bk 都指向自身，而这个 自身，却是 bin 所在位置往前 0x10 字节的地址，即在全局 main_arena 结构体中，.data 段的地址。

下面分别介绍一下各个 bin 中值得一提的特性。

fastbinsY 数组中保存着不同长度的单链表头指针，但实际上数组的大小会比链表总数要略大一些，空出来的可能是留着过年。

#define MAX_FAST_SIZE (80 * SIZE_SZ / 4) // 0x50/0xa0

以 32 位程序为例，只用到了 0x10, 0x18, … 0x40 共 7 个 bin，但数组总大小为 11，fastbin 的上限是 0x50 字节；

对于 64 位程序，也是只用到了 0x20, 0x30, …, 0x80 共 7 个 bin，数组大小为 10，理论上最大的 fastbin 可以达到 0xa0 字节；

fastbin 的特性如下:

  • 进入 fastbin 的 chunk，其 in-use 位为 1，因此不参与相邻块的合并；
  • 同一个 bin 中所有的 chunk 大小都相等，因此不需要排序；
  • 由于 fastbin 是按照最小 chunk 对齐大小增长的，因此从 fastbin 中分配的块必然是 exact fit 的，即申请 chunk 大小与 bin 大小完全一致；
  • LIFO，这是为了提升 cache 命中率；

待释放的块 P 进入 fastbin 时，首先获取对应大小 bin 链表头的指针，称为 FP，然后执行以下操作将 P 插入单链表的头部:

P->fd = *FB;
*FB = P;

同理，要从 fastbin 取出块时，则直接取出链表头的元素:

P = *FP;
*FP = P->fd;

这些指针操作是触发堆漏洞时候构造内存读写原语的重要来源，因此值得重点关注。

  • 只有一个，即 bin_at(1) = bins[0]/bins[1] (fd/bk)；
  • 内部的 chunk 可以是任何大小，且如其名字而言，不进行排序；
  • 双链表，FIFO；
  • 只有一次重新被使用的机会；
  • 对于小请求，大部分情况下要求 exact fit，即尺寸一样才会返回；但如果此时bin 中只剩下一个 chunk 且为 last_remainder 且足够大，会对其进行分割，此时是 best fit；
  • 分割后多出的部分或者遍历时不满足要求的 chunk 会全部放回到各自的 small/large bin 中；
  • 进入 unsorted bin 之前，会先进行前后合并；

待释放的块 P 进入 unsorted bin 时，会插入到 bin 的第一个元素中，如下:

bck = unsorted_chunks(av);
fwd = bck->fd;

P->fd = fwd;
P->bk = bck;
if (!in_smallbin_range(size)) {
    p->fd_nextsize = NULL;
    p->bk_nextsize = NULL;
}
bck->fd = p;
fwd->bk = p;

注意这里用到了本节开头提到的双链表 trick，bck 是双链表的头，这里可以看做是一个 chunk (虽然实际上不是)。 因此，上述双链表插入的时候，并没有像 fastbin 一样直接替换表头，而是插在了表头的后面。

既然是 FIFO，而且在插入时候从表头的 fd 插入，那么取出时自然就优先从链表末尾即 bk 拿出了，取出的相关操作如下:

while ((victim = unsorted_chunks (av)->bk) != unsorted_chunks (av))
{
    bck = victim->bk;

    /* remove from unsorted list */
    unsorted_chunks (av)->bk = bck;
    bck->fd = unsorted_chunks (av);
}

要说特点，Small Bin 可以说是在这些数据结构中最平平无奇的了，包含了一些似乎大家都有的性质，比如:

  • 双链表，FIFO；
  • 每个 bin 中 chunk 的大小都相同；
  • 从中分配的策略属于 best fit；

事实上，small 和 large bin 中的分配策略都属于 best fit，在 malloc 搜索并处理完 unsoted bin 后会对 SB/LB 进行扫描，选出最合适的取出并根据情况进行切割;而 SB/LB 中的 chunk 可能还是刚刚从 UB 中脱出来的。

但也有一些特别的，由于指定 bin 中的 chunk 大小都相同，所以也可以将其中 chunk 的大小称为 bin 的大小。

  • Small Bin 本应有 NSMALLBINS = 64 个，但 bin_at(0) 不存在，bin_at(1) 是 unsorted bin，因此实际上只有 62 个；
  • 在 64 位程序中；
    • 最小的 small bin 大小为 0x20，最大为 0x3f0；
    • 每个 bin 之间的大小相差 0x10；
  • 在 32 位程序中:
    • 最小的 small bin 大小为 0x10，最大为 0x1f8；
    • 每个 bin 之间的大小相差 0x8；

如果没有失忆的话，应该会发现，small bin 和 fast bin 的大小范围有所重叠。但它们的业务范围不同，前者是 unsorted bin 投胎失败后的去处；而后者则是赵家人优待窗口，释放后可以不通过 unsorted bin 直接进入。

更上层的还有天龙人 tcache，后文会详细介绍。

这里先说出链操作，其实和 unsorted bin 类似，都是双链表的删除操作，取的是链表末尾的 chunk:

#define last(b)      ((b)->bk)

idx = smallbin_index (nb);
bin = bin_at (av, idx);
if ((victim = last (bin)) != bin) {
    bck = victim->bk;
    bin->bk = bck;
    bck->fd = bin;
}

入链相对复杂，在于 regular bin 都只能从 unsorted bin 的残羹冷炙中获取生源。但复杂的是算法，数据操作还是很简单的:

victim_index = smallbin_index (size);
bck = bin_at (av, victim_index);
fwd = bck->fd;

victim->bk = bck;
victim->fd = fwd;
fwd->bk = victim;
bck->fd = victim;

bck 是链表头，一个伪 chunk，所以上面的代码本质还是将 victim chunk 插入到链表的头(的下一个位置)。

前文说过，NBINS 一共就 128 个， Small Bin(等等) 占了 64 个，那么剩下来的就是 Large Bin 了。它和其他 bin 相比尽管有一些类似，但更多的是不同。其特性如下:

  • 同一个 bin 中块的大小可以不同，不同大小的块需要经过排序，相同大小的采用 FIFO 顺序进出；
  • bin 中包含两个双链表；
  • 取出时候按照 best fit 的原则获取；
  • 不同的 bin 可以分为 6 组，每组的 bin 之间大小间隔公差不同，见下表；
bin_at bins 间隔 HEX 备注
0-63 64 16 0x10 62 个 Small Bin, [0x20, 0x400)
64-95 32 64 0x40 Large Bin, [0x400, 0xc00)
96-111 16 512 0x200 Large Bin, [0xc00, 0x2c00)
112-119 8 4096 0x1000 Large Bin, [0x2c00, 0xac00)
120-123 4 32768 0x8000 Large Bin, [0xac00, 0x2ac00)
124-125 2 262144 0x40000 Large Bin, [0x2ac00, 0xaac00)
126 1 其他 - Large Bin, [0xaac00, …)

上面备注的 large bin 每组大小区间可能有点不准确，我是按照间隔大小以及文档中所声明的 bin 个数计算的。但分组本身并不很重要，实际计算以 largebin_index_64 宏的结果为准(比如第一组实际上是 64~96)。

largebin 中不同 size 的 chunk 使用 fd_nextsize/bk_nextsize 相连，相同 size 的使用 fd/bk 指针相连，例如下图 bin 中有 7 个 chunk:

largebin

关键点:

  • 链表头的 fd 指向最大的块；bk 指向最小的块；
  • 相同大小的块中，只有第一个块的 fd_nextsize 和 bk_nextsize 指向下一个大小的块，后续块的 fd_nextsize、bk_nextsize 会置零；
  • fd_nextsize/bk_nextsize 属性构成一个循环双链表，从 fd 第一个元素开始 ，fd_nextsize 指向下一个更小的块，最小的块会指向最大的块；注意这个双链表并不包含所有的块；
  • fd/bk 属性也构成一个循环双链表，从表头第一个元素开始 fd 指向下一个 size 小于等于自身 size 的块，串起了所有的块；
  • nextsize 双链表不包含表头，因为表头是个伪 chunk，只有 fd 和 bk 属性；

插入 large bin 的流程伪代码如下:

victim_index = largebin_index (size);
bck = bin_at (av, victim_index);
fwd = bck->fd;

if (fwd != bck) {
    // 与 bin 中最小的块比较
    if (size < chunksize_nomask(bck->bk)) {
        fwd = bck;
        bck = bck->bk;

        victim->fd_nextsize = fwd->fd;
        victim->bk_nextsize = fwd->fd->bk_nextsize;
        fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim;
    } else {
        // 从 fwd = bin->bk 即最大的块开始搜索
        while (size < chunksize_nomask (fwd)) {
           fwd = fwd->fd_nextsize;
        }
        /* 此时 fwd 指向能满足申请 size 的最小块 */
        if (size == chunksize_nomask (fwd)) {
            // 如果已经存在对应大小的块，插入对应次级链表的第二个位置
            fwd = fwd->fd;
        } else {
            victim->fd_nextsize = fwd;
            victim->bk_nextsize = fwd->bk_nextsize;
            fwd->bk_nextsize = victim;
            victim->bk_nextsize->fd_nextsize = victim;
        }
        bck = fwd->bk;
    }
} else { // bin 为空
    victim->fd_nextsize = victim->bk_nextsize = victim;
}

victim->bk = bck;
victim->fd = fwd;
fwd->bk = victim;
bck->fd = victim;

代码虽然看起来很复杂，但思路其实很直观，bck 和 fwd 分别表示待插入块所在位置的前后节点，前面一系列操作只是确定其位置，最后执行双链表的插入操作。而对于 fd/bk_nextsize 的操作也和上图中介绍的流程一致，目的还是为了让 chunk 按照大小顺序排好。

删除 large bin 的逻辑也类似:

bin = bin_at (av, idx);
victim = first (bin); // victim = 最大的块
victim = victim->bk_nextsize; // victim = 最小的块
while (((size = chunksize (victim)) < nb)) {
    // 从小到大搜索，直至尺寸满足
    victim = victim->bk_nextsize;
}

if (victim != last (bin)
    && chunksize_nomask (victim) == chunksize_nomask (victim->fd)) {
    // 如果相同尺寸的块不止一个，从第二个开始取，防止修改 nextsize 链表
    victim = victim->fd;
}

unlink_chunk (av, victim);

unlink_chunk 就是老版本中的 unlink 宏，现在已经升级为了函数，但操作还是一样的，标准双链表删除，其中针对 largebin 的还执行了 nextsize 双链表的删除操作:

unlink_chunk (mstate av, mchunkptr p) {
    mchunkptr fd = p->fd;
    mchunkptr bk = p->bk;
    fd->bk = bk;
    bk->fd = fd;
    /* 确认为 largebin 且 p 在 nextsize 链表中 */
    if (!in_smallbin_range (chunksize_nomask (p)) && p->fd_nextsize != NULL) {
        if (fd->fd_nextsize == NULL) {
            /* 下一个块不在链表中，将其加入 */
            if (p->fd_nextsize == p)
                fd->fd_nextsize = fd->bk_nextsize = fd;
            else {
                fd->fd_nextsize = p->fd_nextsize;
                fd->bk_nextsize = p->bk_nextsize;
                p->fd_nextsize->bk_nextsize = fd;
                p->bk_nextsize->fd_nextsize = fd;
            }
        } else {
            /* 下一个块也在链表中，功成身退 */
            p->fd_nextsize->bk_nextsize = p->bk_nextsize;
            p->bk_nextsize->fd_nextsize = p->fd_nextsize;
        }
    }
}

由前面的逻辑可以推测，如果同样大小的块有不止一个，那么肯定不会删除在 nextsize 双链表中的那个(即第一个)。因此，如果需要从 nextsize 链表中删除，就说明了对应大小的块只有一个。其实这个预设可以简化删除的逻辑，但 unlink 作为通用的函数，不能对传入的 p 做额外预设，因此还是检查了所有情况。

tcache 也是个缓存，本身就是个数组，比 fastbin 快那么一丢丢，但胜在支持的尺寸多。其主要特性如下:

  • 一共有 TCACHE_MAX_BINS = 64 个 tcache bin；
  • 每个 bin 最多只有 TCACHE_FILL_COUNT = 7 个 chunk；
  • bin 之间大小相差 0x10，实际尺寸到索引通过 csize2tidx 计算；
  • 最大的 bin 支持的大小为 0x410，实际用户申请的大小要减去头部和对齐；

其实 tcache 从 2.26 加入 glibc 之后，其结构和代码逻辑都发生了很大的变化。早期什么检查都没有，但每一代都会新增一些校验，导致 tcache 已经不是那么好利用了，所以现在基本上都是先将其填满，然后再去利用常规方法进行利用。

算法

这里简单把堆分配和释放的过程记录下来。在遇到一些细节的时候可以去查看相关代码。

内存的关键分配过程如下:

  1. 如果 tcache 中有合适的块，直接取出返回；
  2. 如果 fastbin 中有合适的块，直接返回；
  3. 如果是小块，则尝试从对应的 smallbin 中取出返回；
  4. 如果是大块，先 malloc_consolidate；
  5. 循环遍历 unsorted bin:
    1. 如果请求的是小块，且 bin 中只有一块 last_remainder，且大小满足，则对其进行切割，然后返回；
    2. 不管要不要，先将当前块从 unsorted bin 中删除；
    3. 如果当前块大小和请求大小完全相等，可直接返回；
    4. 否则将当前块放到对应的 small、large bin 中；
  6. 如果是大块，在 large bin 中搜索最合适的；
  7. 兜底方案，从 top_chunk 中分裂出新的块并返回；

关于 tcache 的横刀夺爱:

  • 在第 2 和 第 3 步，相同大小的其他块也会取出放到对应的 tcache bin 中；
  • 在 5.3 步，并不直接返回，而是先放到 tcache bin 中然后继续遍历；
  • 在 unsorted bin 每次循环的末尾会检查 tcache 有没有拿够，拿够了就放人；

接着看内存释放的过程:

  1. 如果对应的 tcache bin 有空位，直接放进去；
  2. 如果是 fastbin 的大小，放到对应的 fastbin 中；
  3. 尝试合并相邻低地址的块，也称为后向合并(backward)；
  4. 如果相邻高地址的块不是 top chunk，则尝试前向合并(forward)；
    • 否则直接合并然后更新 top chunk，直接返回；
  5. 将合并后的块放到 unsorted bin 中；
  6. 合并后的块大小如果大于某个阈值，则触发 malloc_consolidate；
  7. 如果 top chunk 大于 mp.trim_threshold，则执行 systrim；

其中 malloc_consolidate 在内存分配的时候也遇到过，主要作用是将 fastbin 中的块都清空并归还系统，能与 top chunk 合并的就合并，不能合并的就插入 unsorted bin 的头部。

不管是 malloc_consolidate 还是 systrim，其目的都是为了减少内存碎片，后者的作用是作为 sysmalloc 的逆操作，通过 brk 系统调用将多余的内存还给系统。

后记

本文算是把 ptmalloc 复习了一遍，重新梳理了其中的亿点细节，并编撰成文以备日后参考。其实很多 CTF 比赛还是能够对现实安全研究带来思路的，去享受，去学习，去分享，也许这才是 CTF 的原本价值吧。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/07/17/ptmalloc-notes/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> ptmalloc与glibc堆漏洞利用 https://evilpan.com/2020/04/12/glibc-heap-exp/ Sun, 12 Apr 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/04/12/glibc-heap-exp/ 关于libc的堆管理和利用分析可以说是月经贴，在RSS或者论坛时不时就能看到一篇。对于这种情况，我只想说：这个月，该我了 :)

前言

大家都知道在Linux中，或者说glibc中，动态分配/释放内存使用的是malloc/free函数。那么malloc中获得的内存，是从哪来的呢？一个直观想法是可以通过系统调用直接转发给kmalloc，但这样效率太低。用户态的事，尽量在用户态解决。因此，另一个直观想法就是需要时申请一片空间，然后在用户态管理和分配这些空间。

堆分配器的目的和原理是大同小异的，各个不同的堆分配器区别主要体现在分配和管理策略上。

概念

先不看分配策略，malloc中的空间是从何而来的呢？了解的朋友应该都知道是通过brk/mmap系统调用实现。mmap如其名字所言，在进程的虚拟地址空间中创建新的地址映射；可以简单理解为直接向内核分配一定数量的页，POSIX兼容：

#include <sys/mman.h>

void *
mmap(void *addr, size_t len, int prot, int flags,
	 int fd, off_t offset);

在实际的系统中，mmap一般支持多种类型的映射，比如支持直接将文件映射到内存中。

brk在应用层直接使用较少，但却历史悠久。在brk(2)中介绍，其主要作用是修改program break的位置。那么什么是program break呢？传统上一个进程在内存中会分成不同的片段(segments)：

  • 代码段(text/code segment)：包含可执行的代码
  • 数据段(data segment)：包含编译器所知道的全局或者静态变量
  • 栈(stack segment)：包含一连串的栈空间

当然现在比以前更加复杂，包含只读数据段(.rodata)、未初始化的数据段(.bss)、mmap数据段、vdso段等。

按照传统的划分，进程动态申请更多内存的方法就是拓展数据段，并对拓展出来的空间进行管理。而program break，实际上就是数据段的末尾。

可以通过下面代码看brk的实际效果(sbrk返回新分配空间的指针)：

int main() {
    void *addr;
    addr = sbrk(0);
    addr = sbrk(1);
    return 0;
}

第一次返回0x56558000，对应的内存区域如下：

0x56557000 0x56558000 rw-p     1000 1000   /pwn/test_brk

第二次返回0x56558000，对应的内存区域如下：

0x56557000 0x56558000 rw-p     1000 1000   /pwn/test_brk
0x56558000 0x56559000 rw-p     1000 0      [heap]

可以看出sbrk是以页大小(0x1000)进行分配的，值得一提的是，第一次brk(0)调用之后所返回的地址，实际上就是.data段末尾的地址，这时候该地址还是没有映射的。如果两次brk中使用了printf，则结果则会大不相同。

总之，mmap和brk都是通过系统调用向内核申请新的映射(虚拟空间)，brk在内核中可以认为是mmap对应未初始化数据匿名映射的简化实现。

dlmalloc

在介绍ptmalloc之前，我想先介绍下dlmalloc，因为ptmalloc很大程度上是基于dlmalloc的。

dlmalloc这名字其实是作者的名字——Doug Lea，这在早期算是一个很受欢迎的堆分配器，在保证内存碎片的情况下也兼顾了分配和释放的速度。我们重点关注dlmalloc算法的核心元素，而不会涉及具体的代码实现。

在dlmalloc和许多其他的堆分配器中，内存的分配和管理都是以块(chunk)为单位进行的，这样更容易进行组织。一个chunk就是一段大小固定的内存空间。

dlmalloc中一个重要的数据结构处理就是Boundary Tag，即边界标签。每个chunk都会在开头和结尾处包含额外标签，比如自身的大小和空闲信息。这样做有两个好处：

  1. 两个在地址空间中相邻的空闲chunk可以进行合并，变成一个大的chunk，从而减少内存碎片。
  2. 所有的chunk都可以通过任意一个已知chunk进行正向或者反向遍历找到。

dl1

当然，现代的实现中为了更加充分利用内存，去掉了使用中的chunk末尾的Tag。因为当chunk在使用中时，这些字段是用不到的。

bin可以理解为集装箱，chunk按照大小组织在同一个bin中进行管理(双链表)。最初版本的dlmalloc包含了128个大小固定的bin，每个bin的大小近似地按照对数进行增长。

dl2

小于512的bin都只包含相同大小的chunk，寻找可用chunk采用的是best-fit策略。注意到前面说相邻的free chunk会进行合并，合并后的chunk会视情况放到下一个大bin中；而当分配时如果某个bin没有可用chunk，那么也是会从下一个bin中进行分裂，过程类似于Linux伙伴系统的分配策略。

大于512的bin使用的是另外一种分配策略(malloc_tree_chunk)。

除了这两大核心概念，dlmalloc的实现还考虑了局部性，临界chunk(brk/mmap)和缓存的优化，这里就不展开了。更多细节参考以下资料：

ptmalloc

ptmalloc从dlmalloc中fork而来，其名字(pthread-malloc)也预示着其对多线程的支持，在2006年集成到glibc中作为默认堆分配器实现。因此本文所讨论的ptmalloc，更准确地说是glibc中的ptmalloc，而不是最初的版本。

通常系统的堆内存是一段巨大的连续空间，ptmalloc将其分隔为多个不同的空间以优化多线程中的使用。每个这样的空间称之为arena。多个arena的存在可以让多个线程同时在多个arena中分配内存，从而提高运行效率。

值得一提的是，glibc中的malloc实现不需要保证chunk的大小为2的指数。不论每个chunk大小是多少，相邻的空闲chunk都能进行合并。这样进一步减少了内存碎片以及额外的内存开销。

以下的介绍中涉及的代码主要出自glibc-2.27，因为这是ubuntu18.04的默认版本，操作系统默认为64位。所有其他版本可以从这里下载：

ptmalloc的核心算法和dlmalloc类似，宏观地介绍如下：

  • 对于较大的内存请求(≥512字节)，这是个纯粹的best-fit分配器，通常符合FIFO先进先出的特性。
  • 对于较小的内存请求(≤64字节)，这是个缓存分配器，即从内存池中管理快速回收的chunk。
  • 对于在这之间的内存请求，组合使用上述两个方法，尽量尝试同时满足两个目标。
  • 对于巨大的内存请求(≥128KB)，通常使用系统的mmap调用进行分配。

这就是算法的整体思路。对于多线程场景，主线程堆空间(main arena)同样是通过brk进行增长，而其他线程(per thread arena)则通过mmap进行分配。这也可以理解，因为brk只能增长program break，可内存在多个线程中是共享的，所以只有另寻他处。

与dlmalloc核心元素类似，ptmalloc中有类似的chunk和bin的概念，实现中涉及到的数据结构主要有三个，下文分别介绍。

malloc_chunk结构表示内存中的一个chunk的头部(header)，其定义如下：

/*
  This struct declaration is misleading (but accurate and necessary).
  It declares a "view" into memory allowing access to necessary
  fields at known offsets from a given base. See explanation below.
*/
struct malloc_chunk {

  INTERNAL_SIZE_T      mchunk_prev_size;  /* Size of previous chunk (if free).  */
  INTERNAL_SIZE_T      mchunk_size;       /* Size in bytes, including overhead. */

  struct malloc_chunk* fd;         /* double links -- used only if free. */
  struct malloc_chunk* bk;

  /* Only used for large blocks: pointer to next larger size.  */
  struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */
  struct malloc_chunk* bk_nextsize;
};

不过就像注释所说比较容易让人误解，即误以为这些数据都是保存在每个chunk的头部的，实际上并非如此。

实际上这里也应用了dlmalloc中所提出的Boundary Tag技术，即在chunk头部和尾部包含size等信息(Tag)，方便空闲chunk进行合并。由于free chunk本身是没有内容的，所以利用这个特点来将前一个chunk的Tag保存在free chunk的头部中，而当前free chunk的Tag则顺延，从而减少一个word大小。示例图如下：

    chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of previous chunk, if unallocated (P clear)  |
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of chunk, in bytes                     |A|M|P|
      mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             User data starts here...                          .
	    .                                                               .
	    .             (malloc_usable_size() bytes)                      .
	    .                                                               |
nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             (size of chunk, but used for application data)    |
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	    |             Size of next chunk, in bytes                |A|0|1|
	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

也就是说，free chunk和inuse chunk的头部内容并不相同。举例而言，如果前一个chunk空闲，那么mchunk_prev_size就是有意义的，否则只是包含了上一个chunk的用户数据；还有fd、bk指针对于inuse chunk来说也并不存在。

另外，对于Boundary Tag技术而言，这里Tag就是chunk_size本身，由于chunk的大小是8字节对齐的，因此最低log8=3位用不到，就腾出来记录额外信息，这3个bit从高到低分别是：

  • A：NON_MAIN_ARENA，也简写做N，表示chunk是否属于main arena
  • M：IS_MMAPPED，表示chunk所属空间是否为mmap而来
  • P：PREV_INUSE，表示前一个chunk是否空闲

一个heap指的是一片连续的内存空间，其中包含了许多(可聚结)的malloc_chunk，heap通过mmap进行分配并且起始地址总是HEAP_MAX_SIZE对齐的。heap_info结构描述的就是一个heap：

typedef struct _heap_info
{
  mstate ar_ptr; /* Arena for this heap. */
  struct _heap_info *prev; /* Previous heap. */
  size_t size;   /* Current size in bytes. */
  size_t mprotect_size; /* Size in bytes that has been mprotected
                           PROT_READ|PROT_WRITE.  */
  /* Make sure the following data is properly aligned, particularly
     that sizeof (heap_info) + 2 * SIZE_SZ is a multiple of
     MALLOC_ALIGNMENT. */
  char pad[-6 * SIZE_SZ & MALLOC_ALIGN_MASK];
} heap_info;

每个thread arena中最初包含一个heap，当其内存用完后，会继续分配新的heap并加入到thread arena中。新分配的heap与之前的heap很可能不再是内存连续的了。

注：main arena使用brk拓展内存，只有一个heap，因此不存在heap_info。

上面说了一个arena可以包含一个或者多个heap，其中描述arena的数据结构就是malloc_state。

struct malloc_state
{
  /* Serialize access.  */
  __libc_lock_define (, mutex);

  /* Flags (formerly in max_fast).  */
  int flags;

  /* Set if the fastbin chunks contain recently inserted free blocks.  */
  /* Note this is a bool but not all targets support atomics on booleans.  */
  int have_fastchunks;

  /* Fastbins */
  mfastbinptr fastbinsY[NFASTBINS];

  /* Base of the topmost chunk -- not otherwise kept in a bin */
  mchunkptr top;

  /* The remainder from the most recent split of a small request */
  mchunkptr last_remainder;

  /* Normal bins packed as described above */
  mchunkptr bins[NBINS * 2 - 2];

  /* Bitmap of bins */
  unsigned int binmap[BINMAPSIZE];

  /* Linked list */
  struct malloc_state *next;

  /* Linked list for free arenas.  Access to this field is serialized
     by free_list_lock in arena.c.  */
  struct malloc_state *next_free;

  /* Number of threads attached to this arena.  0 if the arena is on
     the free list.  Access to this field is serialized by
     free_list_lock in arena.c.  */
  INTERNAL_SIZE_T attached_threads;

  /* Memory allocated from the system in this arena.  */
  INTERNAL_SIZE_T system_mem;
  INTERNAL_SIZE_T max_system_mem;
};

glibc不同版本有些许差异，但核心还是相近的，其中就包含了dlmalloc提到的bin。

main_arena的malloc_state是一个全局变量。

一个chunk的头部是malloc_chunk，根据其所处的位置和状态，大致有以下几种类型：

  • Allocated Chunk
  • Free Chunk
  • Top Chunk
  • Last Reminder Chunk

Allocated Chunk即已经返回给用户使用中的chunk，假设返回给用户的指针值是intprt_t mem，那么有mem = chunk + 8，此时chunk的大小即Boundary Tag保存在chunk + 4。

  • prev_size：根据size的PREV_INUSED值，prev_size可能包含前一个free chunk的size信息也可能包含前一个allocated chunk的用户内容。
  • size：当前chunk的tag，即size和A/M/P位信息。

Free Chunk是用户释放掉的chunk，此时fd和bk指针就有意义了，用来链接到对应bin的双链表中。

  • prev_size：总是前一个allocated chunk的用户数据，因为任意两个相邻的free chunk会进行合并，因此前一个chunk肯定不是free chunk
  • size：同
  • fd：forward pointer，指向bin双链表的下一个chunk
  • bk：backward pointer，指向双链表的上一个chunk

Top Chunk是最高的一个chunk，因为位于可用堆地址空间的末端，因此不保存在任何bin中。dlmalloc中将其大小设置为大于任何一个chunk，这样在所有bin都无法满足分配时，就从top chunk中获取；在top chunk的空间也不足的时候才通过系统调用去拓展空间。

Last Remainder Chunk在dlmalloc中是提高局部性分配的一种优化，其本身指向的是最近一次small request分配所分裂(所剩余)的空间。

ptmalloc继承了dlmalloc的Binning特性，不同类别的chunk集装在同一个bin中。在malloc_state中涉及到的bin如下：

...
  /* Fastbins */
  mfastbinptr fastbinsY[NFASTBINS];
...
  /* Normal bins packed as described above */
  mchunkptr bins[NBINS * 2 - 2];

每个bin本质上是一个元素为malloc_chunk指针的链表，这里用数组保存了所有的bin。

FastbinsY：包含所有fastbin的数组，其中的chunk称为fastchunk，fastchunk的最大size为80 * SIZE_SZ / 4，32位下是80字节，64位为160字节。

bins：包含了除fastbin以外的所有bin。与dlmalloc一样，小于512字节的bin包含的是同样大小的chunk，bin之间的大小为8字节递增。直接引用注释的说明如下：

    64 bins of size       8
    32 bins of size      64
    16 bins of size     512
     8 bins of size    4096
     4 bins of size   32768
     2 bins of size  262144
     1 bin  of size what's left

各个bin根据其作用不同，也被赋予了不同的名字，下面详细解释。

fastbin的作用是用来保存最近释放的small chunk。因此和其他bin不同的是fastbin为单链表而不是双链表，因为fastbin中的chunk不会从中间进行删除。同时，fastbin使用更快的LIFO处理顺序而不是其他bin中的FIFO。

保存到fastbin中的chunk的in_use位会被保留，也就是说fastchunk不会和相邻的chunk进行自动合并，但是fastbin可以释放所有chunk进行主动合并。

fastbin的数量和CPU位数有关，但本质都是从小到大递增8或16字节(SIZE_SZ * 2)，直至其最大的大小80 * SIZE_SZ / 4。

unsorted bin中保存的是所有其他chunk分裂生下来的chunk以及所有刚释放返回的chunk，不论大小。

这样处理的目的是给这些最近释放的chunk在被进入到对应bin之前一次重新被使用的机会。因此可以把unsorted bin看作是一个队列，进入其中的chunk要么被释放、合并，要么被取出继续使用或者放到其他bin中。

unsorted bin中的chunkNON_MAIN_ARENA 总是为0。

unsorted bin只有一个，即bin[1]。

smallbin中保存的是小于MIN_LARGE_SIZE的chunk，即small chunk。前面也说过，小于512字节的每个bin保存的都是相同大小的chunk，并且以8字节大小进行递增。

由于smallbin中chunk大小都是相同的，因此不需要进行排序。每个smallbin都是双链表，从头部加入，从尾部删除(返回给用户)，遵循先进先出的顺序(FIFO)。

smallbin从bin[2]开始，共NSMALLBINS个。

largebin中保存的是大于等于MIN_LARGE_SIZE字节的chunk，与smallbin不一样的是，largebin中的chunk大小在同一个范围，但并不是完全相同的。largebin中的chunk需要按照size从大到小进行排序，所分配和释放的额外开销要大于smallbin。

largebin紧邻着smallbin，每个largebin大小范围根据bin的位置不同而不同，随着大小范围越大，bin的数量也就越少。

对于large chunk而言，在malloc_chunk中除了fd和bk指针，还包含了fd_nextsize和bk_nextsize指针，指向不同大小的chunk。

tcache(per-thread cache)在glibc2.26中引入，进一步提升堆管理性能。

/* We overlay this structure on the user-data portion of a chunk when
   the chunk is stored in the per-thread cache.  */
typedef struct tcache_entry
{
  struct tcache_entry *next;
} tcache_entry;

/* There is one of these for each thread, which contains the
   per-thread cache (hence "tcache_perthread_struct").  Keeping
   overall size low is mildly important.  Note that COUNTS and ENTRIES
   are redundant (we could have just counted the linked list each
   time), this is for performance reasons.  */
typedef struct tcache_perthread_struct
{
  char counts[TCACHE_MAX_BINS];
  tcache_entry *entries[TCACHE_MAX_BINS];
} tcache_perthread_struct;

tcache_entry用于链接空闲的chunk，指针直接指向chunk的userdata部分，也就是说复用了指针的含义。

每个线程都会维护一个tcache_prethread_struct，它是整个tcache机制的管理结构，其中包含TCACHE_MAX_BINS个tcache_entry链表。链入其中的chunk大小相同，所以通常也叫做tcache bin。其特性如下：

  • 每个tcache bin最多只能有7个(TCACHE_FILL_COUNT )chunk
  • tcache bin中chunk的inuse位不会置零，也就是说不会进行合并
  • LIFO

可以看到其特性和fastbin是非常类似的。释放时在填满tcache之后才进入传统的释放过程，分配时也先从tcache中搜索。

tcache bin一共有64个(TCACHE_MAX_BINS)，其大小范围为：

/* With rounding and alignment, the bins are...
   idx 0   bytes 0..24 (64-bit) or 0..12 (32-bit)
   idx 1   bytes 25..40 or 13..20
   idx 2   bytes 41..56 or 21..28
   etc.  */

由于tcache的增加和删除非常简洁，因此速度很快，但另一方面这也意味着缺乏各种安全检查和mitigation，在利用时候也格外方便。

在分析分配和释放的具体流程上，最好的方法其实是阅读源码(RTFSC)，也有的人喜欢看一步步的文字解释。我这里按照自己阅读源码的过程将其简化为伪代码，或许可以更直观一些。

再次提醒，所分析的libc版本为2.27

_int_malloc

该函数代码近千行，梳理主要逻辑的伪代码如下：

void *_int_malloc(size) {
	size_t nb = req2size(size);
	chunkptr victim;
	if (nb <= get_max_fast()) {
		// 定位对应的fastbin，并在头部取出(FILO)
		// 如果开启tcache，还会将bin中其他相同大小的chunk全部转移到tcache中
	}

	if (in_smallbin_range(size)) {
		// 定位对应的smallbin，并在尾部取出，即bin->bk(FIFO)
		// 如果开启tcache，还会将bin中其他相同大小的chunk全部转移到tcache中
	} else {
		// 请求为large request，因此需要先清理fastbin
		malloc_consolidate(av);
	}
	
	// 在unsorted_bin中搜索
	foreach(chunk : unsorted_bin) {
		if (is_small && only_chunk && chunk_size > nb) {
			// 分裂这个chunk，更新last_remainder并返回
		}
		if (chunk_size == nb) {
			// 如果没开启tcache，直接返回
			// 如果开启tcache，则先放到tcache，再次循环从tcache中取
		} 
		// 只有一次机会，不是合适的chunk，直接释放到对应的bin中
		if (in_smallbin_range(size)) {
			// 放到对应的smallbin 头部
		} else {
			// 放到对应的largbin中，按照大小排序
		}
		
		if (in_tcache) return tcache_get();
	}

	if (!in_smallbin_range (nb)) {
		// 在largebin中搜索，找到就返回
	}
	
	for (bin in bins) {
		// 通过bitmap在smallbin中搜索，找到就返回
	}
	
use_top:
	// 都找不到合适的chunk，中top_chunk中分裂
	// 如果不足以分离，通过sysalloc扩充top_chunk
}

值得一提的是tcache的搜索在_int_malloc之前，优先级最高：

void *__libc_malloc(size) {
	if (in_tcache) return tcache_get();
	return _int_malloc(size);
}

_int_free

释放逻辑的伪代码如下：

static void
_int_free (mstate av, mchunkptr p) {
	size_t size = chunksize (p);
	if (tcache) { 
		// 放到tcachebin中
	}
	
	if (size <= get_max_fast()) {
		// 将chunk放到对应fastbin的头部
	} else if (!chunk_is_mmapped(p)) {
		if (!prev_inuse(p)) {
			// 后向合并(backward)
			p = prev_chunk(p);
			unlink(av, p, bck, fwd);
		}
		if (nextchunk != av->top) {
			if (!nextinuse) {
				// 前向合并(forward)
				unlink(av, nextchunk, bck, fwd);
				size += nextsize;
			}
			// 将chunk放到unsorted bin中
		} else {
			// 将chunk与top_chunk合并，并成为新的top_chuck
			av->top = p;
		}
		if (size > FASTBIN_CONSOLIDATION_THRESHOLD) {
			// 如果释放的空间太大，就通过systrim回收给系统
			malloc_consolidate(av);
			systrim(heap);
		}

	} else {
		munmap_chunk(p);
	}
}

free中这些操作大都是围绕两个目的：

  1. 减少内部碎片
  2. 加快下次分配的速度

记住这两点，那么其中的许多操作也就比较容易理解了。

另外由于篇幅原因，分析中省略了各种安全相关的assert，因为这和具体的libc版本有关，实际利用布局时需要根据具体的代码进行适配。

漏洞利用

漏洞利用的核心是在产生非预期的操作时，通过内存布局实现读写或者控制流劫持。堆漏洞利用也一样，我们的目标是通过小小的漏洞去构造出蝴蝶效应，在代码和数据的有序交互中开辟出一条新的道路。

glibc的漏洞利用已经有很多优秀的资料了，比如：

因此我们主要介绍几个典型，而不深入各个House的细节之中。

Binning是基于双链表而构造的，而在双链表中一个典型操作就是删除某个结点，也就是unlink操作。以fd和bk作为链表指针为例，unlink的实现一般是：

void unlink(chunk *c) {
	FD = c->fd;
	BK = c->bk;
	FD->bk = BK;
	BK->fd = FD;
}

本质是让前后的结点绕过自己而进行连结。这个操作本身没有问题，但是却经常被攻击者滥用。

假设fd和bk的偏移分别为off_fd和off_bk，那么上述操作转换为内存读写是：

FD = *(c + fd_off);
BK = *(c + bk_off);
*(FD + bk_off) = BK; // 3
*(BK + fd_off) = FD; // 4

如果攻击者可以控制被unlink的chunk中的内容，即FD、BK的值是可控的话，那么就可以构造FD为目的地址x-bk_off，且BK为攻击者控制的地址y。则第3步就可以简化成：

*x = y;

如果x是某个已知会被调用的函数指针地址，那就可以将其覆盖为BK，令BK指向我们的shellcode即可实现控制流劫持。当然这时候BK+fd_off处会被修改，实际构造shellcode可以跳过这几个字节。

其实除了ptmalloc，很多代码中只要有双向链表都会有类似的unlink操作，比如之前安卓内核中的的CVE-2019-2215，所以这类常见的pattern还是值得深入研究的。

堆的单字节溢出在现实中通常更为常见。涉及到堆越界的基本上都和堆的数据结构(头部内容)强相关，所以这里着重讨论gblic的情况。

在可以溢出1字节的情况下，我们可以修改的区域为相邻的下一个chunk的size字段，因为prev_size实际上是在当前chunk的data部分的。溢出的思路有以下几种：

一、 拓展被释放块：当溢出的下一个chunk已经被释放并且存放在unsorted bin中时，通修改一字节将其扩大，这样下一次分配该chunk时后面的块就会被包含从而造成进一步溢出。

  0x100   0x100    0x80
|-------|-------|-------|
|   A   |   B   |   C   |   初始状态
|-------|-------|-------|
|   A   |   B   |   C   |   释放 B
|-------|-------|-------|
|   A   |   B   |   C   |   溢出 B 的 size 为 0x180
|-------|-------|-------|
|   A   |   B   |   C   |   malloc(0x180-8)
|-------|-------|-------|   C 块被覆盖
        |<-- malloced-->|

二、拓展已分配块：当溢出块的下一块为使用中的块，则需要合理控制溢出的字节，使其被释放时的合并操作能够顺利进行，例如直接加上下一块的大小使其完全被覆盖。

下一次分配对应大小时，即可取得已经被扩大的块，并造成进一步溢出。

  0x100   0x100    0x80
|-------|-------|-------|
|   A   |   B   |   C   |   初始状态
|-------|-------|-------|
|   A   |   B   |   C   |   溢出 B 的 size 为 0x180 (C->prev_size)
|-------|-------|-------|
|   A   |   B   |   C   |   释放 B
|-------|-------|-------|
|   A   |   B   |   C   |   malloc(0x180-8)
|-------|-------|-------|   C 块被覆盖
        |<-- malloced-->|

三、poison_null_byte：收缩被释放块，使其在之后分裂此块时将无法正确更新后一块的prev_size，导致释放时出现重叠的堆块。常用于null byte溢出中。

  0x100       0x210       0x80
|-------|---------------|-------|
|   A   |       B       |   C   |   初始状态
|-------|---------------|-------|
|   A   |       B       |   C   |   释放 B
|-------|---------------|-------|
|   A   |       B       |   C   |   溢出 B 的 size 为 0x200
|-------|---------------|-------|   之后的 malloc 操作没有更新 C 的 prev_size
         0x100  0x80
|-------|------|-----|--|-------|
|   A   |  B1  | B2  |  |   C   |   malloc(0x100-8), malloc(0x80-8)
|-------|------|-----|--|-------|
|   A   |  B1  | B2  |  |   C   |   释放 B1
|-------|------|-----|--|-------|
|   A   |  B1  | B2  |  |   C   |   释放 C，C 将与 B1 合并
|-------|------|-----|--|-------|  
|   A   |  B1  | B2  |  |   C   |   malloc(0x180-8)
|-------|------|-----|--|-------|   从B1开始，B2 将被覆盖
        |<-malloced->|

通常B2是一个目标结构体，包含我们想要控制的有价值的指针。

四、 house_of_einherjar：同样是null byte溢出，不过覆盖后的下一个块prev_size可以找到前一个合法的块，并与其进行合并。

  0x100   0x100   0x101
|-------|-------|-------|
|   A   |   B   |   C   |   初始状态
|-------|-------|-------|
|   A   |   B   |   C   |   释放 A
|-------|-------|-------|
|   A   |   B   |   C   |   溢出 B，覆盖 C 块的 size 为 0x200，并使其 prev_size 为 0x200
|-------|-------|-------|
|   A   |   B   |   C   |   释放 C
|-------|-------|-------|
|   A   |   B   |   C   |   C 将与 A 合并
|-------|-------|-------|   B 块被重叠
|<----- malloced ------>|

如果是针对时间紧张的CTF场景，还是要对常见版本的libc利用烂熟于心，比如how2heap命名的那些。当然要想熟悉利用技巧，对于malloc和free的代码实现也需要不断加深理解。

  • house_of_spirit：构造一个fake chunk并进行free，加入到fastbin之后令下一次分配相同的大小返回我们的fake chunk(LIFO)。这种方法的关键点是需要配置好fd指针以及下一个chunk的size以满足各种检查。
  • house_of_force：溢出到top_chunk，修改其size，从而令所有超大的分配都能从top_chunk返回而不通过mmap；然后通过malloc(&top-x)大小的分配返回任意地址。
  • house_of_lore：(< 2.26)，利用smallbin和largebin在头部插入尾部取出的特性(FIFO)，伪造bin中某个chunk的bk指针，这样在chunk出链之后下一个分配的就是我们的fake chunk。
  • house_of_orange：(< 2.26)，类似force，不过是将top chunk的size改小，从而令分配时拓展top chunk，旧的top chunk进入unsorted bin。
  • house_of_einherjar：(< 2.26)，Hiroki Matsukuma提出的单字节溢出的利用技巧，溢出修改前面相邻chunk的size和prev_in_use位，令其在释放时与我们的chunk进行合并，从而令malloc返回任意地址。
  • house_of_botcake：绕过tcache double free的技巧。
  • house_of_rabiit：构造fastbin fake chunk，并通过触发malloc consolidate来令其成为合法的chunk。
  • house_of_roman：RCE through Leakless HeapFengShui, fastbin alloc anywhere.
  • …

No more house, plz.

后记

漏洞利用的本质是内存布局，而内存布局的本质是通过可控的异常去修改程序本身有限状态机的逻辑，从而达到任意读写/控制流劫持等目的。为此，我们在脑海中就要对所exploit的目标运行流程有清晰的认识，不能有丝毫不确定性，0就是0，1就是1。即便在多任务高并发的场景中，比如内核，其涉及的不确定性本身也是确定的。成功的攻击除了统顾全局，对细节的把握也至关重要。

参考资料

]]>