search

6.1.14 pwn 32C3CTF2015 readme

下载文件arrow-up-right

hashtag
题目复现

$ file readme.bin
readme.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=7d3dcaa17ebe1662eec1900f735765bd990742f9, stripped
$ checksec -f readme.bin
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FORTIFY Fortified Fortifiable  FILE
No RELRO        Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   Yes     1               2       readme.bin

开启了 Canary。

flag 就藏在二进制文件中的 .data 段上：

$ rabin2 -z readme.bin | grep 32C3
000 0x00000d20 0x00600d20  31  32 (.data) ascii 32C3_TheServerHasTheFlagHere...

程序接收两次输入，并打印出第一次输入的字符串（看起来并没有格式化字符串漏洞）：

$ ./readme.bin
Hello!
What's your name? %p.%p.%p.%p
Nice to meet you, %p.%p.%p.%p.
Please overwrite the flag: %d.%d.%d.%d
Thank you, bye!
$ python -c 'print "A"*300 + "\n" + "B"' > crash_input
$ ./readme.bin < crash_input
Hello!
What's your name? Nice to meet you, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.
Please overwrite the flag: Thank you, bye!
*** stack smashing detected ***: ./readme.bin terminated
Aborted (core dumped)
$ python -c 'print "A" + "\n" + "B"*300' | ./readme.bin
Hello!
What's your name? Nice to meet you, A.
Please overwrite the flag: Thank you, bye!

第一次输入的字符串过多会导致栈冲突的问题，第二次的输入似乎就没有什么影响。

感觉和 6.1.13 那题一样，都是需要利用 __stack_chk_fail() 打印 flag（参考章节 4.12）。但这一题是动态链接程序，因为 libc-2.25 版本的更新，使 __stack_chk_fail() 不能用了。所以为了复现，我们选择Ubuntu 16.04，版本是 libc-2.23。

hashtag
题目解析

来看一下程序的逻辑：

看注释已经很明显了，第一次的输入需要我们触发栈溢出，使程序调用 __stack_chk_fail()，并打印出 argv[0]。第二次的输入将覆盖掉位于 0x00600d20 的 flag。

hashtag
漏洞利用

那么问题来了，如果 flag 被覆盖掉了，那还怎样将其打印出来。这就涉及到了 ELF 文件的映射问题，我们知道 x86-64 程序的映射是从 0x400000 开始的：

在调试时我们又发现 readme.bin 被映射到下面的两个地址中：

所以只要在二进制文件 0x00000000~0x00001000 范围内的内容都会被映射到内存中，分别以 0x600000 和 0x400000 作为起始地址 。flag 在 0x00000d20，所以会在内存中出现两次，分别位于 0x00600d20 和 0x00400d20：

所以即使 0x00600d20 的 flag 被覆盖了，0x00400d20 的 flag 依然存在。

让我们来找出 argv[0] 距离栈的距离：

536=0x218 个字节。第一次尝试：

在第一个终端里执行下面的命令，相当于远程服务器，并且将 stderr 重定向到 stdout：

然后在第二个终端里执行 exp：

咦，flag 并没有在我们执行 exp 的终端里打印出来，反而是打印在了执行程序的终端里：

所以我们需要做点事情，让远程服务器上的错误信息通过网络传到我们的终端里。即利用第二次的输入，将 LIBC_FATAL_STDERR_=1 写入到环境变量中。结果如下：

函数 __GI___libc_secure_getenv 成功获取到了环境变量 LIBC_FATAL_STDERR_ 的值 1：

Bingo!!!

hashtag
exploit

最终的 exp 如下：

hashtag
参考资料

Previous6.1.13 pwn 34C3CTF2017 readme_revengeNext6.1.15 pwn 34C3CTF2017 SimpleGC

Last updated