- 简介
- 一、基础知识篇
- 二、工具篇
- 三、分类专题篇
- 四、技巧篇
- 五、高级篇
- 六、题解篇
- 6.1 Pwn
- 6.1.1 pwn HCTF2016 brop
- 6.1.2 pwn NJCTF2017 pingme
- 6.1.3 pwn XDCTF2015 pwn200
- 6.1.4 pwn BackdoorCTF2017 Fun-Signals
- 6.1.5 pwn GreHackCTF2017 beerfighter
- 6.1.6 pwn DefconCTF2015 fuckup
- 6.1.7 pwn 0CTF2015 freenote
- 6.1.8 pwn DCTF2017 Flex
- 6.1.9 pwn RHme3 Exploitation
- 6.1.10 pwn 0CTF2017 BabyHeap2017
- 6.1.11 pwn 9447CTF2015 Search-Engine
- 6.1.12 pwn N1CTF2018 vote
- 6.1.13 pwn 34C3CTF2017 readme_revenge
- 6.1.14 pwn 32C3CTF2015 readme
- 6.1.15 pwn 34C3CTF2017 SimpleGC
- 6.1.16 pwn HITBCTF2017 1000levels
- 6.1.17 pwn SECCONCTF2016 jmper
- 6.1.18 pwn HITBCTF2017 Sentosa
- 6.1.19 pwn HITBCTF2018 gundam
- 6.1.20 pwn 33C3CTF2016 babyfengshui
- 6.1.21 pwn HITCONCTF2016 Secret_Holder
- 6.1.22 pwn HITCONCTF2016 Sleepy_Holder
- 6.1.23 pwn BCTF2016 bcloud
- 6.1.24 pwn HITCONCTF2016 HouseofOrange
- 6.1.25 pwn HCTF2017 babyprintf
- 6.1.26 pwn 34C3CTF2017 300
- 6.1.27 pwn SECCONCTF2016 tinypad
- 6.1.28 pwn ASISCTF2016 b00ks
- 6.1.29 pwn Insomni'hackteaserCTF2017 TheGreatEscapepart-3
- 6.1.30 pwn HITCONCTF2017 Ghostinthe_heap
- 6.1.31 pwn HITBCTF2018 mutepig
- 6.1.32 pwn SECCONCTF2017 vmnofun
- 6.1.33 pwn 34C3CTF2017 LFA
- 6.1.34 pwn N1CTF2018 memsafety
- 6.1.35 pwn 0CTF2018 heapstorm2
- 6.1.36 pwn NJCTF2017 messager
- 6.1.37 pwn sixstarctf2018 babystack
- 6.1.38 pwn HITCONCMT2017 pwn200
- 6.1.39 pwn BCTF2018 houseofAtum
- 6.1.40 pwn LCTF2016 pwn200
- 6.1.41 pwn PlaidCTF2015 PlaidDB
- 6.1.42 pwn hacklu2015 bookstore
- 6.1.43 pwn 0CTF2018 babyheap
- 6.1.44 pwn ASIS2017 start_hard
- 6.1.45 pwn LCTF2016 pwn100
- 6.2 Reverse
- 6.3 Web
- 6.1 Pwn
- 七、实战篇
- 7.1 CVE
- 7.1.1 CVE-2017-11543 tcpdump sliplink_print 栈溢出漏洞
- 7.1.2 CVE-2015-0235 glibc _nsshostnamedigitsdots 堆溢出漏洞
- 7.1.3 CVE-2016-4971 wget 任意文件上传漏洞
- 7.1.4 CVE-2017-13089 wget skipshortbody 栈溢出漏洞
- 7.1.5 CVE–2018-1000001 glibc realpath 缓冲区下溢漏洞
- 7.1.6 CVE-2017-9430 DNSTracer 栈溢出漏洞
- 7.1.7 CVE-2018-6323 GNU binutils elfobjectp 整型溢出漏洞
- 7.1.8 CVE-2010-2883 Adobe CoolType SING 表栈溢出漏洞
- 7.1.9 CVE-2010-3333 Microsoft Word RTF pFragments 栈溢出漏洞
- 7.1 CVE
- 八、学术篇
- 8.1 The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)
- 8.2 Return-Oriented Programming without Returns
- 8.3 Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms
- 8.4 ROPdefender: A Detection Tool to Defend Against Return-Oriented Programming Attacks
- 8.5 Data-Oriented Programming: On the Expressiveness of Non-Control Data Attacks
- 8.7 What Cannot Be Read, Cannot Be Leveraged? Revisiting Assumptions of JIT-ROP Defenses
- 8.9 Symbolic Execution for Software Testing: Three Decades Later
- 8.10 AEG: Automatic Exploit Generation
- 8.11 Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software
- 8.13 New Frontiers of Reverse Engineering
- 8.14 Who Allocated My Memory? Detecting Custom Memory Allocators in C Binaries
- 8.21 Micro-Virtualization Memory Tracing to Detect and Prevent Spraying Attacks
- 8.22 Practical Memory Checking With Dr. Memory
- 8.23 Evaluating the Effectiveness of Current Anti-ROP Defenses
- 8.24 How to Make ASLR Win the Clone Wars: Runtime Re-Randomization
- 8.25 (State of) The Art of War: Offensive Techniques in Binary Analysis
- 8.26 Driller: Augmenting Fuzzing Through Selective Symbolic Execution
- 8.27 Firmalice - Automatic Detection of Authentication Bypass Vulnerabilities in Binary Firmware
- 8.28 Cross-Architecture Bug Search in Binary Executables
- 8.29 Dynamic Hooks: Hiding Control Flow Changes within Non-Control Data
- 8.30 Preventing brute force attacks against stack canary protection on networking servers
- 8.33 Under-Constrained Symbolic Execution: Correctness Checking for Real Code
- 8.34 Enhancing Symbolic Execution with Veritesting
- 8.38 TaintEraser: Protecting Sensitive Data Leaks Using Application-Level Taint Tracking
- 8.39 DART: Directed Automated Random Testing
- 8.40 EXE: Automatically Generating Inputs of Death
- 8.41 IntPatch: Automatically Fix Integer-Overflow-to-Buffer-Overflow Vulnerability at Compile-Time
- 8.42 Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software
- 8.43 DTA++: Dynamic Taint Analysis with Targeted Control-Flow Propagation
- 8.44 Superset Disassembly: Statically Rewriting x86 Binaries Without Heuristics
- 8.45 Ramblr: Making Reassembly Great Again
- 8.46 FreeGuard: A Faster Secure Heap Allocator
- 8.48 Reassembleable Disassembling
- 九、附录
4.12 利用 __stack_chk_fail
回顾 canary
在章节 4.4 中我们已经知道了有一种叫做 canary 的漏洞缓解机制,用来判断是否发生了栈溢出。
这一节我们来看一下,在开启了 canary 的程序上,怎样利用 __stack_chk_fail
泄漏信息。
一个例子:
#include <stdio.h>
void main(int argc, char **argv) {
printf("argv[0]: %s\n", argv[0]);
char buf[10];
scanf("%s", buf);
// argv[0] = "Hello World!";
}
我们先注释掉最后一行:
$ gcc chk_fail.c
$ python -c 'print "A"*50' | ./a.out
argv[0]: ./a.out
*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)
可以看到默认情况下 argv[0]
是指向程序路径及名称的指针,然后错误信息中打印出了这个字符串。
然后解掉注释再来看一看:
$ python -c 'print "A"*50' | ./a.out
argv[0]: ./a.out
*** stack smashing detected ***: Hello World! terminated
Aborted (core dumped)
由于程序中我们修改 argv[0]
,此时错误信息就打印出了 Hello World!
。是不是很神奇。
main 函数的反汇编结果如下:
gef➤ disassemble main
Dump of assembler code for function main:
0x00000000004005f6 <+0>: push rbp
0x00000000004005f7 <+1>: mov rbp,rsp
=> 0x00000000004005fa <+4>: sub rsp,0x30
0x00000000004005fe <+8>: mov DWORD PTR [rbp-0x24],edi
0x0000000000400601 <+11>: mov QWORD PTR [rbp-0x30],rsi
0x0000000000400605 <+15>: mov rax,QWORD PTR fs:0x28
0x000000000040060e <+24>: mov QWORD PTR [rbp-0x8],rax
0x0000000000400612 <+28>: xor eax,eax
0x0000000000400614 <+30>: mov rax,QWORD PTR [rbp-0x30]
0x0000000000400618 <+34>: mov rax,QWORD PTR [rax]
0x000000000040061b <+37>: mov rsi,rax
0x000000000040061e <+40>: mov edi,0x4006f4
0x0000000000400623 <+45>: mov eax,0x0
0x0000000000400628 <+50>: call 0x4004c0 <printf@plt>
0x000000000040062d <+55>: lea rax,[rbp-0x20]
0x0000000000400631 <+59>: mov rsi,rax
0x0000000000400634 <+62>: mov edi,0x400701
0x0000000000400639 <+67>: mov eax,0x0
0x000000000040063e <+72>: call 0x4004e0 <__isoc99_scanf@plt>
0x0000000000400643 <+77>: mov rax,QWORD PTR [rbp-0x30]
0x0000000000400647 <+81>: mov QWORD PTR [rax],0x400704
0x000000000040064e <+88>: nop
0x000000000040064f <+89>: mov rax,QWORD PTR [rbp-0x8]
0x0000000000400653 <+93>: xor rax,QWORD PTR fs:0x28 # 检查 canary 是否相同
0x000000000040065c <+102>: je 0x400663 <main+109> # 相同
0x000000000040065e <+104>: call 0x4004b0 <__stack_chk_fail@plt> # 不相同
0x0000000000400663 <+109>: leave
0x0000000000400664 <+110>: ret
End of assembler dump.
所以当 canary 检查失败的时候,即产生栈溢出,覆盖掉了原来的 canary 的时候,函数不能正常返回,而是执行 __stack_chk_fail()
函数,打印出 argv[0]
指向的字符串。
libc 2.23
Ubuntu 16.04 使用的是 libc-2.23,其 __stack_chk_fail()
函数如下:
// debug/stack_chk_fail.c
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__stack_chk_fail (void)
{
__fortify_fail ("stack smashing detected");
}
调用函数 __fortify_fail()
:
// debug/fortify_fail.c
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn)) internal_function
__fortify_fail (const char *msg)
{
/* The loop is added only to keep gcc happy. */
while (1)
__libc_message (2, "*** %s ***: %s terminated\n",
msg, __libc_argv[0] ?: "<unknown>");
}
libc_hidden_def (__fortify_fail)
__fortify_fail()
调用函数 __libc_message()
打印出错误信息和 argv[0]
。
还有一个错误信息输出到哪儿的问题,再看一下 __libc_message()
:
// sysdeps/posix/libc_fatal.c
/* Abort with an error message. */
void
__libc_message (int do_abort, const char *fmt, ...)
{
va_list ap;
int fd = -1;
va_start (ap, fmt);
#ifdef FATAL_PREPARE
FATAL_PREPARE;
#endif
/* Open a descriptor for /dev/tty unless the user explicitly
requests errors on standard error. */
const char *on_2 = __libc_secure_getenv ("LIBC_FATAL_STDERR_");
if (on_2 == NULL || *on_2 == '\0')
fd = open_not_cancel_2 (_PATH_TTY, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1)
fd = STDERR_FILENO;
环境变量 LIBC_FATAL_STDERR_
通过函数 __libc_secure_getenv
来读取,如果该变量没有被设置或者为空,即 \0
或 NULL
,错误信息 stderr 会被重定向到 _PATH_TTY
,该值通常是 /dev/tty
,因此会直接在当前终端打印出来,而不是传到 stderr。
CTF 实例
CTF 中就有这样一种题目,需要我们把 argv[0]
覆盖为 flag 的地址,并利用 __stack_chk_fail()
把flag 给打印出来。
实例可以查看章节 6.1.13 和 6.1.14。
libc 2.25
最后我们来看一下 libc-2.25 里的 __stack_chk_fail
:
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__stack_chk_fail (void)
{
__fortify_fail_abort (false, "stack smashing detected");
}
strong_alias (__stack_chk_fail, __stack_chk_fail_local)
它使用了新函数 __fortify_fail_abort()
,这个函数是在 BZ #12189 这次提交中新增的:
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__fortify_fail_abort (_Bool need_backtrace, const char *msg)
{
/* The loop is added only to keep gcc happy. Don't pass down
__libc_argv[0] if we aren't doing backtrace since __libc_argv[0]
may point to the corrupted stack. */
while (1)
__libc_message (need_backtrace ? (do_abort | do_backtrace) : do_abort,
"*** %s ***: %s terminated\n",
msg,
(need_backtrace && __libc_argv[0] != NULL
? __libc_argv[0] : "<unknown>"));
}
void
__attribute__ ((noreturn))
__fortify_fail (const char *msg)
{
__fortify_fail_abort (true, msg);
}
libc_hidden_def (__fortify_fail)
libc_hidden_def (__fortify_fail_abort)
函数 __fortify_fail_abort()
在第一个参数为 false
时不再进行栈回溯,直接以打印出字符串 <unknown>
结束,也就没有办法输出 argv[0]
了。
就像下面这样:
$ python -c 'print("A"*50)' | ./a.out
argv[0]: ./a.out
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)
参考资料
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论