修改TCB来绕过canary

C12en

2023-02-17

stack

以往做过的开启了canary保护的题目一般都是通过格式化字符串泄露从而来绕过canary 最近在学习免杀的时候意外了解了canary的生成机制从而就有了今天的这一篇文章总体下来还是收获颇丰

什么是canary

由于c语言并没有检查数组的下标所以其存在溢出的可能性诱发了栈溢出漏洞可以使得攻击者任意的控制程序执行流对此 canary机制有效预防了栈溢出的操作

其通过在栈帧的bp寄存器间隔一个字长(往低地址方向)的地方存放了一串随机数(末位为\x00 目的是防止被printf等函数泄露)

在函数结束前进行了一个异或检查如果发现此地址处的canary被修改了那么则判定为发生了栈溢出的行为

则会跳转到**___stack_chk_fail**函数该函数负责输出错误信息并且终止程序

函数栈帧在形成初期从 fs:0x28 赋值并将其入栈

函数结束前进行异或判定如果结尾为0 就通过jz指令跳转到 leave|ret 指令处返回父栈帧

否则就调用**___stack_chk_fail**函数结束程序

而在libc2.23及以下的版本中 ___stack_chk_fail函数会根据argv[0]存放的程序路径来输出下面这样的错误信息

#include<stdio.h>
int main(){
    char a[0x20];
    read(0,a,0x30);
}

而argv[0]位于当前栈帧的栈底可以通过溢出篡改其为flag 从而获取flag

这里直接在源码中修改argv[0] 看看效果

#include<stdio.h>
int main(int argc,char **argv){
    char a[20];
    argv[0]="hello,world";
    read(0,a,0x30);
}

不过要注意的是其输出的是路径也就是字符串而非输出该路径对应文件的内容

接着我们更换一下libc 文件使其为libc2.27再次尝试源码不变

可以发现其直接默认输出unknown了

同时这里发现了一个有趣的现象到达一定长度后溢出的数据会被当作指令执行这就需要进一步研究了

不过由于我实在是太心急把这篇文章写出来所以暂时是先咕咕了后续会开一个新篇章研究这个现象

上述稍微跑题了一下说回canary 栈上的canary是由 fs:28h 处提供的值我们对这个地址朔源一下

fs是一个寄存器其指向当前活动线程的TEB结构

TEB是一个线程环境块进程中每个线程都对应着一个TEB结构体其存储了线程的各种信息

不同的偏移对应着不同的信息

000 指向SEH链指针
004 线程堆栈顶部
008 线程堆栈底部
00C SubSystemTib
010 FiberData
014 ArbitraryUserPointer
018 FS段寄存器在内存中的镜像地址
020 进程PID
024 线程ID
02C 指向线程局部存储指针
030 PEB结构地址（进程结构）
034 上个错误号

但是fs中存放的TEB地址需要经过解析之后才能显示

调用pthread_self函数就可以获取到TEB的位置

可以在对应位置找到canary 而canary判断是否被更改是将栈上的和这里的进行比较

如果我们修改了TEB上的canary 那么栈上的canary就可以很轻易的被我们绕过

那么TEB上的canary又是从何而来呢这就要从内核的_dl_random说起了

其是一个地址用来指向内核中存储随机数的地方

该随机数初始化于动态链接之前

其存放于auxiliary vector 数组中该数组是用来辅助程序运行的数据数组

其在dl_main函数中被调用

ElfW(Addr)
_dl_sysdep_start (void **start_argptr,
     void (*dl_main) (const ElfW(Phdr) *phdr, ElfW(Word) phnum,
          ElfW(Addr) *user_entry, ElfW(auxv_t) *auxv))
{
  ...
  DL_FIND_ARG_COMPONENTS (start_argptr, _dl_argc, _dl_argv, _environ,
         GLRO(dl_auxv));
  for (av = GLRO(dl_auxv); av->a_type != AT_NULL; set_seen (av++))
    ...
   case AT_RANDOM:
   _dl_random = (void *) av->a_un.a_val;
   break;
    ...
  ...
}

接着是__libc_start_main函数其生成canary的源码如下

// sysdeps\unix\sysv\linux\dl-osinfo.h
static inline uintptr_t __attribute__ ((always_inline))
_dl_setup_stack_chk_guard (void *dl_random)
{
  union
  {
    uintptr_t num;
    unsigned char bytes[sizeof (uintptr_t)];
  } ret;

  /* We need in the moment only 8 bytes on 32-bit platforms and 16
     bytes on 64-bit platforms.  Therefore we can use the data
     directly and not use the kernel-provided data to seed a PRNG.  */
  memcpy (ret.bytes, dl_random, sizeof (ret));
#if BYTE_ORDER == LITTLE_ENDIAN
  ret.num &= ~(uintptr_t) 0xff;
#elif BYTE_ORDER == BIG_ENDIAN
  ret.num &= ~((uintptr_t) 0xff << (8 * (sizeof (ret) - 1)));
#else
# error "BYTE_ORDER unknown"
#endif
  return ret.num;
}

canary的值和dl_random一致只不过在最后一个字节强制使其为\x00

接着来到_libc_start_init函数

  /* Set up the stack checker's canary.  */
  uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (_dl_random);
# ifdef THREAD_SET_STACK_GUARD
  THREAD_SET_STACK_GUARD (stack_chk_guard);
# else
  __stack_chk_guard = stack_chk_guard;
# endif

如果设置了THREAD_SET_STACK_GUARD宏那么canary就会被设置进入线程局部存储

PS:一直没有搞清楚TEB TCB pthread三者的关系上述的描述可能存在很大问题更详细的源码级别可以看这篇博客以我的水平很难对其进行复述

浅析 Linux 程序的 Canary 机制 | Kiprey’s Blog