第一次不完整的ctf出题记录
第一次不完整的ctf出题记录
之前都是做题,至此有个机会打算挑战一下自己,出一道题目,了解一下出题的思路和过程。于是有了一个不完整的出题经历。我个人理解的出题思路应该是:
-
写出含有可以用漏洞的源代码
-
以合适的方式进行编译
-
自己编写漏洞利用的思路和代码,拿到Flag
-
出题结束
但是,,,,太菜了,目前只做了前两步,现在想想好像没有什么工作量啊…但还是简单的总结一下吧。
本次总结主要分为三个部分,每个部分包含操作的步骤以及学习到的内容。
- 源代码的编写
- 编译
- 问题
源代码编写
事实上,题目是我根据最近做的一道题目改出来的,所以源代码编写的思路是:将原题的elf文件放进IDA中看它的源代码,然后想办法写一段C代码,使得该代码在编译之后和原题的ELF文件在IDA中的功能等效。
过程
这个题目的思路是:
- 构造一个ELF文件,可以对一个name变量输入一个字符串,产生溢出,覆盖进而修改文件描述符
- 然后通过构造fake file调用FILE中的close()函数,实现劫持程序控制流的目的
- 编译时开启栈保护,需要实现stack pivot,然后构造ROP拿到shell权限
1.在数据段中构造name和fp变量
希望将name和fp变量构造在.bss段,并且name位于低地址,fp位于高地址,使得对name进行输入溢出的时候,可以覆盖fp
都构造在bss段,就需要将这两个变量都设置为全局变量。实现过程中一直都无法将fp放在name的下边,定义形式如下:
一:
char x[20];
FILE* fp=NULL;
二:
char x;
FILE* fp;
三:
FILE* fp=NULL;
char x[20];
四:
FILE* fp;
char x;
尝试的解决方案:
1.编译时设置优化选项
gcc -O0 -O1 -O2
考虑是否是编译器在优化的时候自动将数组分配在高地址。
2.初始化是否影响溢出
样例一:
char x[20];
int a=0;
int main()
{......}
样例二:
char x[20];
int a;
int main()
{......}
现象:当对x输入,产生溢出时,样例一中a没有被修改,样例二中a被修改。
4.将fp和name定义在一个结构体中
fp和name在结构体中的顺序就是在bss段中的顺序,可行!
5.先定义一个int类型,然后在程序中将其赋值为一个FILE地址
char x[20];
int a;
int main()
{
FILE* fp=fopen("random.txt","r");
printf("the size of int is %d\n",sizeof(int));
printf("the size of double is %d\n",sizeof(double));
printf("the size of FILE is %d\n",sizeof(fp));
printf("the value of a is %x\n",a);
printf("input your name:\n");
scanf("%s",x);
printf("a is %x\n",a);
if(a!=0)
{
printf("hhhhhhhhhhhhhhhhh\n");
}
return 0;
}
发现int和FILE*的长度一样,都是4bytes,于是利用这个方法可行!
6.只要int或者double在内存中字节数与FILE* fp(即指针)在内存中的字节数相同,就可以用int或者其他类型来代替指针符号。
证明:
int a;
double b;
FILE* fp=fopen("random.txt");
printf("the size of int is %d\n",sizeof(int));
printf("the size of double is %d\n",sizeof(double));
printf("the size of FILE is %d\n",sizeof(fp));
b=fp;
a=fp;
2.IDA反编译后的v2 = __readgsdword(0x14u);
启动了canary保护;这个不需要在源码中定义,只需要在编译时注意相关选项的设置即可。
3.ssignal(14, (int)handler);
为alarm信号设置handler处理函数。
收获
1.fopen()的返回值与FILE*
fopne()函数的返回值是一个指针,该指针指向FILE结构体的首地址。也就是说,这个指针对应的值是FILE结构体的首地址,而不是FILE结构体的第一个字节的内容。
2.结构体定义
结构体中的定义顺序就是bss段的存放顺序。
编译
在生成ELF文件的时候,一定要注意编译选项的设定,这很大程度上决定了这个题目是否能pwn以及pwn的思路和难度。
过程
gcc -m32 -O0 -Wall
收获
CANNARY(栈保护)
这个选项表示栈保护功能有没有开启。
栈溢出保护是一种缓冲区溢出攻击缓解手段,当函数存在缓冲区溢出攻击漏洞时,攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后,函数开始执行的时候会先往栈里插入cookie信息,当函数真正返回的时候会验证cookie信息是否合法,如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉,导致栈保护检查失败而阻止shellcode的执行。在Linux中我们将cookie信息称为canary。
gcc在4.2版本中添加了-fstack-protector和-fstack-protector-all编译参数以支持栈保护功能,4.9新增了-fstack-protector-strong编译参数让保护的范围更广。
因此在编译时可以控制是否开启栈保护以及程度,例如:
gcc -o test test.c // 默认情况下,不开启Canary保护
gcc -fno-stack-protector -o test test.c //禁用栈保护
gcc -fstack-protector -o test test.c //启用堆栈保护,不过只为局部变量中含有 char 数组的函数插入保护代码
gcc -fstack-protector-all -o test test.c //启用堆栈保护,为所有函数插入保护代码
FORTIFY
fority其实非常轻微的检查,用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数,如memcpy,memset,stpcpy,strcpy,strncpy,strcat,strncat,sprintf,snprintf,vsprintf,vsnprintf,gets以及宽字符的变体。
_FORTIFY_SOURCE设为1,并且将编译器设置为优化1(gcc -O1),以及出现上述情形,那么程序编译时就会进行检查但又不会改变程序功能
_FORTIFY_SOURCE设为2,有些检查功能会加入,但是这可能导致程序崩溃。
gcc -D_FORTIFY_SOURCE=1
仅仅只会在编译时进行检查 (特别像某些头文件 #include <string.h>
)
gcc -D_FORTIFY_SOURCE=2
程序执行时也会有检查 (如果检查到缓冲区溢出,就终止程序)
举个例子可能简单明了一些:
void fun(char *s) {
char buf[0x100];
strcpy(buf, s);
/* Don't allow gcc to optimise away the buf */
asm volatile("" :: "m" (buf));
}
用包含参数-U_FORTIFY_SOURCE编译
08048450 <fun>:
push %ebp ;
mov %esp,%ebp
sub $0x118,%esp ; 将0x118存储到栈上
mov 0x8(%ebp),%eax ; 将目标参数载入eax
mov %eax,0x4(%esp) ; 保存目标参数
lea -0x108(%ebp),%eax ; 数组buf
mov %eax,(%esp) ; 保存
call 8048320 <[email protected]>
leave ;
ret
用包含参数-D_FORTIFY_SOURCE=2编译
08048470 <fun>:
push %ebp ;
mov %esp,%ebp
sub $0x118,%esp ;
movl $0x100,0x8(%esp) ; 把0x100当作目标参数保存
mov 0x8(%ebp),%eax ;
mov %eax,0x4(%esp) ;
lea -0x108(%ebp),%eax ;
mov %eax,(%esp) ;
call 8048370 <[email protected]>
leave ;
ret
我们可以看到gcc生成了一些附加代码,通过对数组大小的判断替换strcpy, memcpy, memset等函数名,达到防止缓冲区溢出的作用。
gcc -o test test.c // 默认情况下,不会开这个检查
gcc -D_FORTIFY_SOURCE=1 -o test test.c // 较弱的检查
gcc -D_FORTIFY_SOURCE=2 -o test test.c // 较强的检查
NX(DEP)
NX即No-eXecute(不可执行)的意思,NX(DEP)的基本原理是将数据所在内存页标识为不可执行,当程序溢出成功转入shellcode时,程序会尝试在数据页面上执行指令,此时CPU就会抛出异常,而不是去执行恶意指令。
gcc编译器默认开启了NX选项,如果需要关闭NX选项,可以给gcc编译器添加-z execstack参数。
例如:
gcc -o test test.c // 默认情况下,开启NX保护
gcc -z execstack -o test test.c // 禁用NX保护
gcc -z noexecstack -o test test.c // 开启NX保护
在Windows下,类似的概念为DEP(数据执行保护),在最新版的Visual Studio中默认开启了DEP编译选项。
PIE(ASLR)
一般情况下NX(Windows平台上称其为DEP)和地址空间分布随机化(ASLR)会同时工作。
内存地址随机化机制(address space layout randomization),有以下三种情况
0 - 表示关闭进程地址空间随机化。
1 - 表示将mmap的基址,stack和vdso页面随机化。
2 - 表示在1的基础上增加栈(heap)的随机化。
可以防范基于Ret2libc方式的针对DEP的攻击。ASLR和DEP配合使用,能有效阻止攻击者在堆栈上运行恶意代码。
Built as PIE:位置独立的可执行区域(position-independent executables)。这样使得在利用缓冲溢出和移动操作系统中存在的其他内存崩溃缺陷时采用面向返回的编程(return-oriented programming)方法变得难得多。
liunx下关闭PIE的命令如下:
sudo -s echo 0 > /proc/sys/kernel/randomize_va_space
gcc编译命令
gcc -o test test.c // 默认情况下,不开启PIE
gcc -fpie -pie -o test test.c // 开启PIE,此时强度为1
gcc -fPIE -pie -o test test.c // 开启PIE,此时为最高强度2
gcc -fpic -o test test.c // 开启PIC,此时强度为1,不会开启PIE
gcc -fPIC -o test test.c // 开启PIC,此时为最高强度2,不会开启PIE
PIE和PIC的区别
RELRO
在Linux系统安全领域数据可以写的存储区就会是攻击的目标,尤其是存储函数指针的区域。 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处.
GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation。大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为只读.
设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号,从而减少对GOT(Global Offset Table)攻击。RELRO为” Partial RELRO”,说明我们对GOT表具有写权限。
gcc -o test test.c // 默认情况下,是Partial RELRO
gcc -z norelro -o test test.c // 关闭,即No RELRO
gcc -z lazy -o test test.c // 部分开启,即Partial RELRO
gcc -z now -o test test.c // 全部开启,即
总结
NX:-z execstack / -z noexecstack (关闭 / 开启)
Canary:-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启)
PIE:-no-pie / -pie (关闭 / 开启)
RELRO:-z norelro / -z lazy / -z now (关闭 / 部分开启 / 完全开启)
问题
-
全局变量在bss段的存储顺序
-
NX表示的不可执行,将数据所在内存页标识为不可执行这个不可执行到底是在哪里不可执行???