diff --git a/doc/6.1.4_pwn_backdoorctf2017_fun_signals.md b/doc/6.1.4_pwn_backdoorctf2017_fun_signals.md index f3dd38c..264047b 100644 --- a/doc/6.1.4_pwn_backdoorctf2017_fun_signals.md +++ b/doc/6.1.4_pwn_backdoorctf2017_fun_signals.md @@ -3,13 +3,15 @@ - [SROP 原理](#srop-原理) - [Linux 系统调用](#linux-系统调用) - [signal 机制](#signal-机制) + - [SROP](#SROP) +- [pwnlib.rop.srop](#pwnlibropsrop) - [BackdoorCTF2017 Fun Signals](#backdoorctf2017-fun-signals) - [参考资料](#参考资料) ## SROP 原理 #### Linux 系统调用 -在开始这一切之前，我想先将一下 Linux 的系统调用。64 位和 32 位的系统调用表分别在 +在开始这一切之前，我想先讲一下 Linux 的系统调用。64 位和 32 位的系统调用表分别在 `/usr/include/asm/unistd_64.h` 和 `/usr/include/asm/unistd_32.h` 中，另外还需要查看 `/usr/include/bits/syscall.h`。 一开始 Linux 是通过 `int 0x80` 中断的方式进入系统调用，它会先进行调用者特权级别的检查，然后进行压栈、跳转等操作，这无疑会浪费许多资源。从 Linux 2.6 开始，就出现了新的系统调用指令 `sysenter`/`sysexit`，前者用于从 Ring3 进入 Ring0，后者用于从 Ring0 返回 Ring3，它没有特权级别检查，也没有压栈的操作，所以执行速度更快。 @@ -18,84 +20,166 @@ ![](../pic/6.4_signal.png) -sigreturn frame 因架构不同而不同，在 Linux 中也有了新的定义，但目前关于 srop 的利用也都是基于旧的 sigcontext，所以这里还是给出旧定义，仅当用户空间依然依赖它时才会使用它们： -``` -# ifdef __i386__ -struct sigcontext { - __u16 gs, __gsh; - __u16 fs, __fsh; - __u16 es, __esh; - __u16 ds, __dsh; - __u32 edi; - __u32 esi; - __u32 ebp; - __u32 esp; - __u32 ebx; - __u32 edx; - __u32 ecx; - __u32 eax; - __u32 trapno; - __u32 err; - __u32 eip; - __u16 cs, __csh; - __u32 eflags; - __u32 esp_at_signal; - __u16 ss, __ssh; - struct _fpstate *fpstate; - __u32 oldmask; - __u32 cr2; -}; -# else /* __x86_64__: */ -struct sigcontext { - __u64 r8; - __u64 r9; - __u64 r10; - __u64 r11; - __u64 r12; - __u64 r13; - __u64 r14; - __u64 r15; - __u64 rdi; - __u64 rsi; - __u64 rbp; - __u64 rbx; - __u64 rdx; - __u64 rax; - __u64 rcx; - __u64 rsp; - __u64 rip; - __u64 eflags; /* RFLAGS */ - __u16 cs; - __u16 gs; - __u16 fs; - union { - __u16 ss; /* If UC_SIGCONTEXT_SS */ - __u16 __pad0; /* Alias name for old (!UC_SIGCONTEXT_SS) user-space */ - }; - __u64 err; - __u64 trapno; - __u64 oldmask; - __u64 cr2; - struct _fpstate *fpstate; /* Zero when no FPU context */ -# ifdef __ILP32__ - __u32 __fpstate_pad; -# endif - __u64 reserved1[8]; -}; -``` +如图所示，当有中断或异常产生时，内核会向某个进程发送一个 signal，该进程被挂起并进入内核（1），然后内核为该进程保存相应的上下文，然后跳转到之前注册好的 signal handler 中处理相应的 signal（2），当 signal handler 返回后（3），内核为该进程恢复之前保存的上下文，最终恢复进程的执行（4）。 -在你使用 `ldd` 命令时，通常也会显示 vDSO，如下： +- 一个 signal frame 被添加到栈，这个 frame 中包含了当前寄存器的值和一些 signal 信息。 +- 一个新的返回地址被添加到栈顶，这个返回地址指向 `sigreturn` 系统调用。 +- signal handler 被调用，signal handler 的行为取决于收到什么 signal。 +- signal handler 执行完之后，如果程序没有终止，则返回地址用于执行 `sigreturn` 系统调用。 +- `sigreturn` 利用 signal frame 恢复所有寄存器以回到之前的状态。 +- 最后，程序执行继续。 + +不同的架构会有不同的 signal frame，下面是 32 位结构，`sigcontext` 结构体会被 push 到栈中： +```C +struct sigcontext +{ + unsigned short gs, __gsh; + unsigned short fs, __fsh; + unsigned short es, __esh; + unsigned short ds, __dsh; + unsigned long edi; + unsigned long esi; + unsigned long ebp; + unsigned long esp; + unsigned long ebx; + unsigned long edx; + unsigned long ecx; + unsigned long eax; + unsigned long trapno; + unsigned long err; + unsigned long eip; + unsigned short cs, __csh; + unsigned long eflags; + unsigned long esp_at_signal; + unsigned short ss, __ssh; + struct _fpstate * fpstate; + unsigned long oldmask; + unsigned long cr2; +}; ``` -$ ldd /usr/bin/ls - linux-vdso.so.1 (0x00007ffff7ffa000) - libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ffff79b2000) - libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff75fa000) - /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ffff7dd8000) +下面是 64 位，push 到栈中的其实是 `ucontext_t` 结构体： +```C +// defined in /usr/include/sys/ucontext.h +/* Userlevel context. */ +typedef struct ucontext_t + { + unsigned long int uc_flags; + struct ucontext_t *uc_link; + stack_t uc_stack; // the stack used by this context + mcontext_t uc_mcontext; // the saved context + sigset_t uc_sigmask; + struct _libc_fpstate __fpregs_mem; + } ucontext_t; + +// defined in /usr/include/bits/types/stack_t.h +/* Structure describing a signal stack. */ +typedef struct + { + void *ss_sp; + size_t ss_size; + int ss_flags; + } stack_t; + +// difined in /usr/include/bits/sigcontext.h +struct sigcontext +{ + __uint64_t r8; + __uint64_t r9; + __uint64_t r10; + __uint64_t r11; + __uint64_t r12; + __uint64_t r13; + __uint64_t r14; + __uint64_t r15; + __uint64_t rdi; + __uint64_t rsi; + __uint64_t rbp; + __uint64_t rbx; + __uint64_t rdx; + __uint64_t rax; + __uint64_t rcx; + __uint64_t rsp; + __uint64_t rip; + __uint64_t eflags; + unsigned short cs; + unsigned short gs; + unsigned short fs; + unsigned short __pad0; + __uint64_t err; + __uint64_t trapno; + __uint64_t oldmask; + __uint64_t cr2; + __extension__ union + { + struct _fpstate * fpstate; + __uint64_t __fpstate_word; + }; + __uint64_t __reserved1 [8]; +}; ``` -32 位程序则会显示 `linux-gate.so.1`，都是一个意思。 +就像下面这样： + +![](../pic/6.1.4_sigret.jpg) + +#### SROP +SROP，即 Sigreturn Oriented Programming，正是利用了 Sigreturn 机制的弱点，来进行攻击。 + +首先系统在执行 `sigreturn` 系统调用的时候，不会对 signal 做检查，它不知道当前的这个 frame 是不是之前保存的那个 frame。由于 `sigreturn` 会从用户栈上恢复恢复所有寄存器的值，而用户栈是保存在用户进程的地址空间中的，是用户进程可读写的。如果攻击者可以控制了栈，也就控制了所有寄存器的值，而这一切只需要一个 gadget：`syscall; ret;`。 + +另外，这个 gadget 在一些系统上没有被内存随机化处理，所以可以在相同的位置上找到，参照下图： + +![](../pic/6.1.4_sigret_aslr.png) + +通过设置 `eax/rax` 寄存器，可以利用 `syscall` 指令执行任意的系统调用，然后我们可以将 `sigreturn` 和 其他的系统调用串起来，形成一个链，从而达到任意代码执行的目的。下面是一个伪造 frame 的例子： + +![](../pic/6.1.4_fake_frame.jpg) + +`rax=59` 是 `execve` 的系统调用号，参数 `rdi` 设置为字符串“/bin/sh”的地址，`rip` 指向系统调用 `syscall`，最后，将 `rt_sigreturn` 设置为 `sigreturn` 系统调用的地址。当 `sigreturn` 返回后，就会从这个伪造的 frame 中恢复寄存器，从而拿到 shell。 + +下面是一个更复杂的例子： + +![](../pic/6.1.4_attack.png) + +1. 首先利用一个栈溢出漏洞，将返回地址覆盖为一个指向 `sigreturn` gadget 的指针。如果只有 `syscall`，则将 RAX 设置为 0xf，也是一样的。在栈上覆盖上 fake frame。其中： + - `RSP`：一个可写的内存地址 + - `RIP`：`syscall; ret;` gadget 的地址 + - `RAX`：`read` 的系统调用号 + - `RDI`：文件描述符，即从哪儿读入 + - `RSI`：可写内存的地址，即写入到哪儿 + - `RDX`：读入的字节数，这里是 306 +2. `sigreturn` gadget 执行完之后，因为设置了 `RIP`，会再次执行 `syscall; ret;` gadget。payload 的第二部分就是通过这里读入到文件描述符的。这一部分包含了 3 个 `syscall; ret;`，fake frame 和其他的代码或数据。 +3. 接收完数据或，`read` 函数返回，返回值即读入的字节数被放到 `RAX` 中。我们的可写内存被这些数据所覆盖，并且 `RSP` 指向了它的开头。然后 `syscall; ret;` 被执行，由于 `RAX` 的值为 306，即 `syncfs` 的系统调用号，该调用总是返回 0，而 0 又是 `read` 的调用号。 +4. 再次执行 `syscall; ret;`，即 `read` 系统调用。这一次，读入的内容不重要，重要的是数量，让它等于 15，即 `sigreturn` 的调用号。 +5. 执行第三个 `syscall; ret;`，即 `sigreturn` 系统调用。从第二个 fake frame 中恢复寄存器，这里是 `execve("/bin/sh", ...)`。另外你还可以调用 `mprotect` 将某段数据变为可执行的。 +6. 执行 `execve`，拿到 shell。 + + +## pwnlib.rop.srop +在 pwntools 中已经集成了 SROP 的利用工具，即 [pwnlib.rop.srop](http://docs.pwntools.com/en/stable/rop/srop.html)，直接使用类 `SigreturnFrame`，我们来看一下它的构造： +```python +>>> from pwn import * +>>> context.arch +'i386' +>>> SigreturnFrame(kernel='i386') +{'es': 0, 'esp_at_signal': 0, 'fs': 0, 'gs': 0, 'edi': 0, 'eax': 0, 'ebp': 0, 'cs': 115, 'edx': 0, 'ebx': 0, 'ds': 0, 'trapno': 0, 'ecx': 0, 'eip': 0, 'err': 0, 'esp': 0, 'ss': 123, 'eflags': 0, 'fpstate': 0, 'esi': 0} +>>> SigreturnFrame(kernel='amd64') +{'es': 0, 'esp_at_signal': 0, 'fs': 0, 'gs': 0, 'edi': 0, 'eax': 0, 'ebp': 0, 'cs': 35, 'edx': 0, 'ebx': 0, 'ds': 0, 'trapno': 0, 'ecx': 0, 'eip': 0, 'err': 0, 'esp': 0, 'ss': 43, 'eflags': 0, 'fpstate': 0, 'esi': 0} +>>> +>>> context.arch = 'amd64' +>>> SigreturnFrame(kernel='amd64') +{'r14': 0, 'r15': 0, 'r12': 0, 'rsi': 0, 'r10': 0, 'r11': 0, '&fpstate': 0, 'rip': 0, 'csgsfs': 51, 'uc_stack.ss_flags': 0, 'oldmask': 0, 'sigmask': 0, 'rsp': 0, 'rax': 0, 'r13': 0, 'cr2': 0, 'r9': 0, 'rcx': 0, 'trapno': 0, 'err': 0, 'rbx': 0, 'uc_stack.ss_sp': 0, 'r8': 0, 'rdx': 0, 'rbp': 0, 'uc_flags': 0, '__reserved': 0, '&uc': 0, 'eflags': 0, 'rdi': 0, 'uc_stack.ss_size': 0} +``` +总共有三种，结构和初始化的值会 有所不同： +- i386 on i386：32 位系统上运行 32 位程序 +- i386 on amd64：64 位系统上运行 32 位程序 +- amd64 on amd64：64 为系统上运行 64 位程序 ## BackdoorCTF2017 Fun Signals +``` +$ file funsignals_player_bin +funsignals_player_bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped +``` 这是一个 64 位静态链接的 srop，可以说是什么都没开。。。 ``` $ checksec -f funsignals_player_bin @@ -168,7 +252,7 @@ fake_flag_here_as_original_is_at_server\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ ``` 如果连接的是远程服务器，`fake_flag_here_as_original_is_at_server` 会被替换成真正的 flag。 -其他文件放在了[github](../src/writeup/6.1.4_pwn_backdoorctf2017_fun_signals)相应文件夹中。 +其他文件放在了 [github](../src/writeup/6.1.4_pwn_backdoorctf2017_fun_signals) 相应文件夹中。 这一节我们详细介绍了 SROP 的原理，并展示了一个简单的例子，在后面的章节中，会展示其更复杂的运用，包扩结合 vDSO 的用法。 @@ -178,3 +262,4 @@ fake_flag_here_as_original_is_at_server\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ - [slides: Framing Signals a return to portable shellcode](https://tc.gtisc.gatech.edu/bss/2014/r/srop-slides.pdf) - [Sigreturn Oriented Programming](https://www.slideshare.net/AngelBoy1/sigreturn-ori) - [Sigreturn Oriented Programming is a real Threat](https://subs.emis.de/LNI/Proceedings/Proceedings259/2077.pdf) +- [Sigreturn Oriented Programming (SROP) Attack攻击原理](http://www.freebuf.com/articles/network/87447.html) diff --git a/doc/6.1.6_pwn_defconctf2015_fuckup.md b/doc/6.1.6_pwn_defconctf2015_fuckup.md index 6703914..025e7dd 100644 --- a/doc/6.1.6_pwn_defconctf2015_fuckup.md +++ b/doc/6.1.6_pwn_defconctf2015_fuckup.md @@ -8,8 +8,21 @@ ## ret2vdso 原理 +在你使用 `ldd` 命令时，通常会显示出 vDSO，如下： +``` +$ ldd /usr/bin/ls + linux-vdso.so.1 (0x00007ffff7ffa000) + libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ffff79b2000) + libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff75fa000) + /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ffff7dd8000) +``` +32 位程序则会显示 `linux-gate.so.1`，都是一个意思。 + + ## 题目解析 ## Exploit ## 参考资料 +- `man vdso` +- [Return to VDSO using ELF Auxiliary Vectors](http://v0ids3curity.blogspot.in/2014/12/return-to-vdso-using-elf-auxiliary.html) diff --git a/pic/6.1.4_attack.png b/pic/6.1.4_attack.png new file mode 100644 index 0000000..f919494 Binary files /dev/null and b/pic/6.1.4_attack.png differ diff --git a/pic/6.1.4_fake_frame.jpg b/pic/6.1.4_fake_frame.jpg new file mode 100644 index 0000000..215677b Binary files /dev/null and b/pic/6.1.4_fake_frame.jpg differ diff --git a/pic/6.1.4_sigret.jpg b/pic/6.1.4_sigret.jpg new file mode 100644 index 0000000..127b551 Binary files /dev/null and b/pic/6.1.4_sigret.jpg differ diff --git a/pic/6.1.4_sigret_aslr.png b/pic/6.1.4_sigret_aslr.png new file mode 100644 index 0000000..51ce207 Binary files /dev/null and b/pic/6.1.4_sigret_aslr.png differ