CTF

tcache stashing unlink attack 在tcache中布置5个chunk，对应大小的small bin中布置2个chunk。修改倒数第二个small chunk的bk指向target，target->bk写入一个可写的位置。使用calloc触发，因为calloc调用_int_malloc不会使用tcache进行分配（除了_int_malloc遍历unsorted bin的尾部），只会往tcache中填充。 可以造成target->bk->fd位置写入大数字，并且target成为tcache中第一个，再次malloc就可以获得。 有点像fastbin reverse into tcache。 variation 在tcache中布置6个chunk，对应大小的small bin中布置2个chunk。（可以用unsorted bin切割的方式布置2个small bin） 修改倒数第二个small chunk的bk，calloc触发，只在bk->fd写入大数字。 ...

house of orange 修改topchunk->size为一个缩小的并且满足页对齐的大小，malloc一个大于size的块（但也不要大于mmap threshold），会导致原来topchunk被放入unsorted bin。 当topchunk不足以分配所需空间时，会调用sysmalloc分配额外空间。一般情况下，main_arena中old top chunk和新分配的top chunk首尾相邻，从而会进行合并。当我们将topchunk->size减小后，会检测不到相邻，也就不会合并了。设置好fencepost chunk，会执行_int_free (av, old_top, 1)将其放入unsorted bin。 代码涉及_int_malloc后边和sysmalloc。 ...

house of einherjar 和house of force很像，都是篡改top chunk。 off-by-one覆盖victim chunk的pre_in_use位，并修改victim->pre_size为距离目标地址的大小，在目标地址处伪造chunk，释放victim时，发生backward consolidate，合并到目标地址。 victim需要临近top chunk，backward consolidate结束，接着与top chunk进行forward consolidate。如果不这样，这个块被放入unsorted bin，而在unsorted bin中分配会过不了以下检查。 1 2 3 4 if (__builtin_expect (chunksize_nomask (victim) <= 2 * SIZE_SZ, 0) || __builtin_expect (chunksize_nomask (victim) > av->system_mem, 0)) malloc_printerr ("malloc(): memory corruption"); ...

large bin attack 对已存在于large bin中的chunk的bk、bk_nextsize字段进行更改，在unsorted bin中取出插入该large bin时，会将bk->fd、bk_nextsize->fd_nextsize的位置覆盖成chunk的地址。涉及的代码就是unsorted bin遍历取出插入那块。和先前的unsorted bin attack类似，通常为进一步攻击做准备，如修改global_max_fast。 这里比较难理解就是large bin的结构，特别是先前我被一个large bin结构图所误导，下面给出我画的结构图（如果有错误o((⊙﹏⊙))o，请帮忙指出）。 0ctf2018 heapstorm2 1 2 3 4 5 Arch: amd64-64-little RELRO: Full RELRO Stack: Canary found NX: NX enabled PIE: PIE enabled 功能分析 程序首先使用mallopt函数将global_max_fast设置为0，也就是不使用fastbin。 ...

unsorted bin attack 对unsorted bin中的chunk->bk进行修改，接下来该chunk分配出去时，chunk->bk->fd就被赋值为unsortedbin头结点地址。 1 2 3 4 bck = victim->bk; /* remove from unsorted list */ unsorted_chunks (av)->bk = bck; bck->fd = unsorted_chunks (av); 在glibc2.28中增加了以下检查，使得此攻击失效。 1 2 if (__glibc_unlikely (bck->fd != victim)) malloc_printerr ("malloc(): corrupted unsorted chunks 3"); unsorted bin attack通常为进一步的攻击做准备，比如覆写global_max_fast。 0ctf2016 zerostorage 1 2 3 4 5 6 Arch: amd64-64-little RELRO: Full RELRO Stack: Canary found NX: NX enabled PIE: PIE enabled FORTIFY: Enabled 关键数据结构 flag：标识该节点是否存在 size：记录大小 content：数据块指针 程序有以下功能 1 2 3 4 5 6 7 1. Insert 2. Update 3. Merge 4. Delete 5. View 6. List 7. Exit insert：获取数据块大小，并读入数据。数据块大小在128~4096这个范围内 update：对数据块进行大小内容进行更新 merge：将两节点合并。这里存在漏洞，输入两次相同的id，导致UAF。这个漏洞我没发现，思维还不够猥琐啊 delete：释放数据块，清空节点 总体思路 通过UAF，首先泄露libc基址，然后修改其bk指针，使用unsorted bin attack修改global_max_fast变量；fastbin bin attack覆写__free_hook为system函数地址。 ...

House of force 溢出修改topchunk的size，分配一个使size_t溢出的evil_size，使下一次分配在目标位置，进行修改。 1 2 3 4 5 6 7 8 9 /* * The evil_size is calulcated as (nb is the number of bytes requested + space for metadata): * new_top = old_top + nb * nb = new_top - old_top * req + 2sizeof(long) = new_top - old_top * req = new_top - old_top - 2sizeof(long) * req = dest - 2sizeof(long) - old_top - 2sizeof(long) * req = dest - old_top - 4*sizeof(long) */ Bctf2016 bcloud 分析 1 2 3 4 5 Arch: i386-32-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x8047000) 程序一开始让输入name、org、hostname，输入字符串函数存在null byte overflow。 输入name函数中，字符串数组在栈中后部紧邻指针变量，所以strcpy会将该指针一并拷贝入0x40的空间（实际可用0x44），并且null byte覆盖topchunk的最低字节。可以泄露堆的地址 输入org、hostname函数中，存在同样问题，可覆盖的更多的字节。可以覆盖topchunk的size ...

overlapping chunks 溢出对unsortedbin中的chunk->size进行修改，造成堆块重叠。 hack.lu2015 bookstore 1 2 3 4 5 Arch: amd64-64-little RELRO: No RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x3ff000) 程序是一个订书系统，在main函数开始处，连续分配3个0x80的空间，一个存储订单1——order1，一个存储订单2——order2，一个存储提示信息——info。有以下功能菜单 1 2 3 4 5 1: Edit order 1 2: Edit order 2 3: Delete order 1 4: Delete order 2 5: Submit Edit order 1/2：order1/order2使用fgetc读取字符串，读到\n终止，所以这里存在溢出 Delete order 1/2：free掉order1/order2。这里存在指针悬空 Submit： 分配0x140的空间（称为orderlist）将order1和order2拼接。这里存在溢出 程序末尾printf(info)存在可能的格式化字符串漏洞。 overlapping chunks && format string vulnerability...

Poison null byte 关于堆块重叠，可以看这篇文章，图文并茂。 glibc2.26中，在unlink宏中加入了size==prev_size(next_chunk)的检查，与下一chunk所存储的pre_size进行了比对，在poison_null_byte.c中相应的添加了*(size_t*)(b+0x1f0) = 0x200，可以绕过这个检查，所以how2heap的README中对glibc的要求是<2.26应该是忘了改。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 chunk b +------> +----------+ | | +----------+ <---------+ size | 0X200 | +----------+ <---------+ b | | | | | | | | | | | | | | | | | | +----------+ <--------+ fake pre_size | 0X200 | +----------+ | | chunk c +------> +----------+ <--------+ pre_size | 0X210 | +----------+ | | | | | | 触发unlink的流程：通过null byte溢出伪造完0x200的chunk后，此时该chunk存在于unsortedbin。再次分配0x100的b1时，遍历unsortedbin，该chunk被放入到smallbin中，unsortedbin里的chunk也就这一个，遍历结束无法分配。又通过查找binmap找到0x200的smallbin，这时触发的unlink，将该chunk从smallbin中取出。 ...

House of Spirit 该攻击手法的主要是思想是，在不可控区域的前后伪造chunk信息，覆盖某指针指向chunk2mem(fake_chunk)，释放该指针后再次申请，对不可控区域的进行改写。 1 2 3 4 5 6 7 8 9 10 11 +---------------+ | 可 控 区 域 | +---------------+ | | | 不 可 控 区 域 | | | | 一 般 为 某 些 | | 指 针 | +---------------+ | 可 控 区 域 | +---------------+ 伪造的chunk也通常是fastbin，因为检查容易绕过。 ...

前置 Ubuntu 16.04 使用how2heap脚本编译glibc2.25，其中的4是编译线程数。脚本中git clone慢，可以替换成tsinghua mirrors，把第83行的git clone git://sourceware.org/git/glibc.git "$SRC" 替换成 git clone https://mirrors.tuna.tsinghua.edu.cn/git/glibc.git "$SRC"。 1 $ ./glibc_build.sh 2.25 -j 4 -disable-tcache 做这道题目使用了glibc2.25，patchelf --set-interpreter /path/to/ld-2.25.so /path/to/exe，patch之后再运行程序就自动使用同目录下libc-2.25.so。 ...