花式栈溢出技巧

stack pivoting

原理

stack pivoting，正如它所描述的，该技巧就是劫持栈指针指向攻击者所能控制的内存处，然后再在相应的位置进行 ROP。一般来说，我们可能在以下情况需要使用 stack pivoting

  • 可以控制的栈溢出的字节数较少，难以构造较长的 ROP 链

  • 开启了 PIE 保护，栈地址未知，我们可以将栈劫持到已知的区域。

  • 其它漏洞难以利用，我们需要进行转换，比如说将栈劫持到堆空间，从而在堆上写 rop 及进行堆漏洞利用

此外，利用 stack pivoting 有以下几个要求

  • 可以控制程序执行流。

  • 可以控制 sp 指针。一般来说，控制栈指针会使用 ROP，常见的控制栈指针的 gadgets 一般是

pop rsp/esp

当然，还会有一些其它的姿势。比如说 libc_csu_init 中的 gadgets，我们通过偏移就可以得到控制 rsp 指针。上面的是正常的，下面的是偏移的。

gef➤  x/7i 0x000000000040061a
0x40061a <__libc_csu_init+90>:	pop    rbx
0x40061b <__libc_csu_init+91>:	pop    rbp
0x40061c <__libc_csu_init+92>:	pop    r12
0x40061e <__libc_csu_init+94>:	pop    r13
0x400620 <__libc_csu_init+96>:	pop    r14
0x400622 <__libc_csu_init+98>:	pop    r15
0x400624 <__libc_csu_init+100>:	ret    
gef➤  x/7i 0x000000000040061d
0x40061d <__libc_csu_init+93>:	pop    rsp
0x40061e <__libc_csu_init+94>:	pop    r13
0x400620 <__libc_csu_init+96>:	pop    r14
0x400622 <__libc_csu_init+98>:	pop    r15
0x400624 <__libc_csu_init+100>:	ret

此外，还有更加高级的 fake frame。

  • 存在可以控制内容的内存，一般有如下

    • bss 段。由于进程按页分配内存，分配给 bss 段的内存大小至少一个页(4k，0x1000)大小。然而一般bss段的内容用不了这么多的空间，并且 bss 段分配的内存页拥有读写权限。

    • heap。但是这个需要我们能够泄露堆地址。

示例

例1

这里我们以 X-CTF Quals 2016 - b0verfl0w 为例进行介绍。首先，查看程序的安全保护，如下

可以看出源程序为 32 位，也没有开启 NX 保护，下面我们来找一下程序的漏洞

可以看出，源程序存在栈溢出漏洞。但是其所能溢出的字节就只有 50-0x20-4=14 个字节，所以我们很难执行一些比较好的 ROP。这里我们就考虑 stack pivoting 。由于程序本身并没有开启堆栈保护，所以我们可以在栈上布置shellcode 并执行。基本利用思路如下

  • 利用栈溢出布置 shellcode

  • 控制 eip 指向 shellcode 处

第一步，还是比较容易地，直接读取即可，但是由于程序本身会开启 ASLR 保护，所以我们很难直接知道 shellcode 的地址。但是栈上相对偏移是固定的，所以我们可以利用栈溢出对 esp 进行操作，使其指向 shellcode 处，并且直接控制程序跳转至 esp处。那下面就是找控制程序跳转到 esp 处的 gadgets 了。

这里我们发现有一个可以直接跳转到 esp 的 gadgets。那么我们可以布置 payload 如下

那么我们 payload 中的最后一部分改如何设置 esp 呢，可以知道

  • size(shellcode+padding)=0x20

  • size(fake ebp)=0x4

  • size(0x08048504)=0x4

所以我们最后一段需要执行的指令就是

所以最后的 exp 如下

例2-转移堆

待。

题目

frame faking

正如这个技巧名字所说的那样，这个技巧就是构造一个虚假的栈帧来控制程序的执行流。

原理

概括地讲，我们在之前讲的栈溢出不外乎两种方式

  • 控制程序 EIP

  • 控制程序 EBP

其最终都是控制程序的执行流。在 frame faking 中，我们所利用的技巧便是同时控制 EBP 与 EIP，这样我们在控制程序执行流的同时，也改变程序栈帧的位置。一般来说其 payload 如下

即我们利用栈溢出将栈上构造为如上格式。这里我们主要讲下后面两个部分

  • 函数的返回地址被我们覆盖为执行 leave ret 的地址，这就表明了函数在正常执行完自己的 leave ret 后，还会再次执行一次 leave ret。

  • 其中 fake ebp 为我们构造的栈帧的基地址，需要注意的是这里是一个地址。一般来说我们构造的假的栈帧如下

这里我们的 fake ebp 指向 ebp2，即它为 ebp2 所在的地址。通常来说，这里都是我们能够控制的可读的内容。

下面的汇编语法是 intel 语法。

在我们介绍基本的控制过程之前，我们还是有必要说一下，函数的入口点与出口点的基本操作

入口点

出口点

其中 leave 指令相当于

下面我们来仔细说一下基本的控制过程。

  1. 在有栈溢出的程序执行 leave 时，其分为两个步骤

    • mov esp, ebp ，这会将 esp 也指向当前栈溢出漏洞的 ebp 基地址处。

    • pop ebp， 这会将栈中存放的 fake ebp 的值赋给 ebp。即执行完指令之后，ebp便指向了ebp2，也就是保存了 ebp2 所在的地址。

  2. 执行 ret 指令，会再次执行 leave ret 指令。

  3. 执行 leave 指令，其分为两个步骤

    • mov esp, ebp ，这会将 esp 指向 ebp2。

    • pop ebp，此时，会将 ebp 的内容设置为 ebp2 的值，同时 esp 会指向 target function。

  4. 执行 ret 指令，这时候程序就会执行 target function，当其进行程序的时候会执行

    • push ebp，会将 ebp2 值压入栈中，

    • mov ebp, esp，将 ebp 指向当前基地址。

此时的栈结构如下

  1. 当程序执行时，其会正常申请空间，同时我们在栈上也安排了该函数对应的参数，所以程序会正常执行。

  2. 程序结束后，其又会执行两次 leave ret addr，所以如果我们在 ebp2 处布置好了对应的内容，那么我们就可以一直控制程序的执行流程。

可以看出在 fake frame 中，我们有一个需求就是，我们必须得有一块可以写的内存，并且我们还知道这块内存的地址，这一点与 stack pivoting 相似。

2018 安恒杯 over

以 2018 年 6 月安恒杯月赛的 over 一题为例进行介绍, 题目可以在 ctf-challenge 中找到

文件信息

64 位动态链接的程序, 没有开 PIE 和 canary 保护, 但开了 NX 保护

分析程序

放到 IDA 中进行分析

漏洞很明显, read 能读入 96 位, 但 buf 的长度只有 80, 因此能覆盖 rbp 以及 ret addr 但也只能覆盖到 rbp 和 ret addr, 因此也只能通过同时控制 rbp 以及 ret addr 来进行 rop 了

leak stack

为了控制 rbp, 我们需要知道某些地址, 可以发现当输入的长度为 80 时, 由于 read 并不会给输入末尾补上 '\0', rbp 的值就会被 puts 打印出来, 这样我们就可以通过固定偏移知道栈上所有位置的地址了

leak 出栈地址后, 我们就可以通过控制 rbp 为栈上的地址(如 0x7ffceaf11160), ret addr 为 leave ret 的地址来实现控制程序流程了。

比如我们可以在 0x7ffceaf11160 + 0x8 填上 leak libc 的 rop chain 并控制其返回到 sub_400676 函数来 leak libc。 ​ 然后在下一次利用时就可以通过 rop 执行 system("/bin/sh") 或 execve("/bin/sh", 0, 0) 来 get shell 了, 这道题目因为输入的长度足够, 我们可以布置调用 execve("/bin/sh", 0, 0) 的利用链, 这种方法更稳妥(system("/bin/sh") 可能会因为 env 被破坏而失效), 不过由于利用过程中栈的结构会发生变化, 所以一些关键的偏移还需要通过调试来确定

exp

总的来说这种方法跟 stack pivot 差别并不是很大。

参考阅读

Stack smash

原理

在程序加了canary 保护之后，如果我们读取的 buffer 覆盖了对应的值时，程序就会报错，而一般来说我们并不会关心报错信息。而 stack smash 技巧则就是利用打印这一信息的程序来得到我们想要的内容。这是因为在程序启动 canary 保护之后，如果发现 canary 被修改的话，程序就会执行 __stack_chk_fail 函数来打印 argv[0] 指针所指向的字符串，正常情况下，这个指针指向了程序名。其代码如下

所以说如果我们利用栈溢出覆盖 argv[0] 为我们想要输出的字符串的地址，那么在 __fortify_fail 函数中就会输出我们想要的信息。

批注： 这个方法在 glibc-2.31 之后不可用了, 具体看这个部分代码 fortify_fail.c 。

总结一下原因就是现在不会打印argv[0] 指针所指向的字符串

32C3 CTF readme

这里，我们以 2015 年 32C3 CTF readme 为例进行介绍，该题目在 jarvisoj 上有复现。

确定保护

可以看出程序为 64 位，主要开启了 Canary 保护以及 NX 保护，以及 FORTIFY 保护。

分析程序

ida 看一下

很显然，程序在 _IO_gets((__int64)&v4); 存在栈溢出。

此外，程序中还提示要 overwrite flag。而且发现程序很有意思的在 while 循环之后执行了这条语句

又看了看对应地址的内容，可以发现如下内容，说明程序的flag就在这里。

但是如果我们直接利用栈溢出输出该地址的内容是不可行的，这是因为我们读入的内容 byte_600D20[v1++] = v2;也恰恰就是该块内存，这会直接将其覆盖掉，这时候我们就需要利用一个技巧了

  • 在 ELF 内存映射时，bss 段会被映射两次，所以我们可以使用另一处的地址来进行输出，可以使用 gdb 的 find来进行查找。

确定 flag 地址

我们把断点下载 memset 函数处，然后读取相应的内容如下

可以看出我们读入的 2222 已经覆盖了 0x600d20 处的 flag，但是我们在内存的 0x400d20 处仍然找到了这个flag的备份，所以我们还是可以将其输出。这里我们已经确定了 flag 的地址。

确定偏移

下面，我们确定 argv[0] 距离读取的字符串的偏移。

首先下断点在 main 函数入口处，如下

可以看出 0x00007fffffffe00b 指向程序名，其自然就是 argv[0]，所以我们修改的内容就是这个地址。同时0x00007fffffffdc58 处保留着该地址，所以我们真正需要的地址是 0x00007fffffffdc58。

此外，根据汇编代码

我们可以确定我们读入的字符串的起始地址其实就是调用 __IO_gets 之前的 rsp，所以我们把断点下在 call 处，如下

可以看出rsp的值为0x7fffffffda40，那么相对偏移为

利用程序

我们构造利用程序如下

这里我们直接就得到了 flag，没有出现网上说的得不到 flag 的情况。

题目

  • 2018 网鼎杯 - guess

栈上的 partial overwrite

partial overwrite 这种技巧在很多地方都适用, 这里先以栈上的 partial overwrite 为例来介绍这种思想。

我们知道, 在开启了随机化（ASLR，PIE）后, 无论高位的地址如何变化，低 12 位的页内偏移始终是固定的, 也就是说如果我们能更改低位的偏移, 就可以在一定程度上控制程序的执行流, 绕过 PIE 保护。

2018-安恒杯-babypie

以安恒杯 2018 年 7 月月赛的 babypie 为例分析这一种利用技巧, 题目的 binary 放在了 ctf-challenge 中

确定保护

64 位动态链接的文件, 开启了 PIE 保护和栈溢出保护

分析程序

IDA 中看一下, 很容易就能发现漏洞点, 两处输入都有很明显的栈溢出漏洞, 需要注意的是在输入之前, 程序对栈空间进行了清零, 这样我们就无法通过打印栈上信息来 leak binary 或者 libc 的基址了

同时也发现程序中给了能直接 get shell 的函数

这样我们只要控制 rip 到该函数即可

leak canary

在第一次 read 之后紧接着就有一个输出, 而 read 并不会给输入的末尾加上 \0, 这就给了我们 leak 栈上内容的机会。

为了第二次溢出能控制返回地址, 我们选择 leak canary. 可以计算出第一次 read 需要的长度为 0x30 - 0x8 + 1 (+ 1 是为了覆盖 canary 的最低位为非 0 的值, printf 使用 %s 时, 遇到 \0 结束, 覆盖 canary 低位为非 0 值时, canary 就可以被 printf 打印出来了)

canary 在 rbp - 0x8 的位置上, 可以看出此时 canary 的低位已经被覆盖为 0x61, 这样只要接收 'a' * (0x30 - 0x8 + 1) 后的 7 位, 再加上最低位的 '\0', 我们就恢复出程序的 canary 了

覆盖返回地址

有了 canary 后, 就可以通过第二次的栈溢出来改写返回地址了, 控制返回地址到 getshell 函数即可, 我们先看一下没溢出时的返回地址

可以发现, 此时的返回地址与 get shell 函数的地址只有低位的 16 bit 不同, 如果覆写低 16 bit 为 0x?A3E, 就有一定的几率 get shell

最终的脚本如下:

需要注意的是, 这种技巧不止在栈上有效, 在堆上也是一种有效的绕过地址随机化的手段

2018-XNUCA-gets

这个题目也挺有意思的，如下

程序就这么小，很明显有一个栈溢出的漏洞，然而没有任何 leak。。

确定保护

先来看看程序的保护

比较好的是程序没有 canary，自然我们很容易控制程序的 EIP，但是控制到哪里是一个问题。

分析

我们通过 ELF 的基本执行流程（可执行文件部分）来知道程序的基本执行流程，与此同时我们发现在栈上存在着两个函数的返回地址。

其中 __libc_start_main+240 位于 libc 中，_dl_init+139 位于 ld 中

一个比较自然的想法就是我们通过 partial overwrite 来修改这两个地址到某个获取 shell 的位置，那自然就是 Onegadget 了。那么我们究竟覆盖哪一个呢？？

我们先来分析一下 libc 的基地址 0x7ffff7a0d000。我们一般要覆盖字节的话，至少要覆盖1个半字节才能够获取跳到 onegadget。然而，程序中读取的时候是 gets读取的，也就意味着字符串的末尾肯定会存在\x00。

而我们覆盖字节的时候必须覆盖整数倍个数，即至少会覆盖 3 个字节，而我们再来看看__libc_start_main+240 的地址 0x7ffff7a2d830，如果覆盖3个字节，那么就是 0x7ffff700xxxx，已经小于了 libc 的基地址了，前面也没有刻意执行的代码位置。

一般来说 libc_start_main 在 libc 中的偏移不会差的太多，那么显然我们如果覆盖 __libc_start_main+240 ，显然是不可能的。

而 ld 的基地址呢？如果我们覆盖了栈上_dl_init+139，即为0x7ffff700xxxx。而观察上述的内存布局，我们可以发现libc位于 ld 的低地址方向，那么在随机化的时候，很有可能 libc 的第 3 个字节是为\x00 的。

举个例子，目前两者之间的偏移为

那么如果 ld 被加载到了 0x7ffff73ca000，则显然 libc 的起始地址就是0x7ffff7000000。

因此，我们有足够的理由选择覆盖栈上存储的_dl_init+139。那么覆盖成什么呢？还不知道。因为我们还不知道 libc 的库版本是什么，，

我们可以先随便覆盖覆盖，看看程序会不会崩溃，毕竟此时很有可能会执行 libc 库中的代码。

最后发现报出了如下错误，一方面，我们可以判断出这肯定是 2.23 版本的 libc；另外一方面，我们我们可以通过(cfree+0x4c)[0x7f57b6f9253c]来最终定位 libc 的版本。

确定好了 libc 的版本后，我们可以选一个 one_gadget，这里我选择第一个，较低地址的。

使用如下 exp 继续爆破，

最后获取到 shell。

题目

Previous基本 ROPNext中级ROP

Last updated