在一些64位的glibc的payload調用system函數失敗問題
當我在做題的時候就發現一個奇怪的事情，我在ubuntu16.04運行成功的exp在ubuntu 18.04卻報出了timeout: the monitored command dumped core的錯誤。我覺得很奇怪，一些新的64位的glibc在控制了程序流后，調用system函數的時候，會直接crash，經過調試之后，終於發現了問題所在。
// gcc -g -no-pie -Og shell.c -o shell
#include <stdlib.h>
int main()
{
system("/bin/sh");
return 0;
}
程序編譯之后是能正常運行的，但是我們要的是讓程序不正常運行。
ldd查看一下所用的libc
我們將libc拷貝出來,分析一下。
我們們把斷點下到這一條指令。
可以看到$rsp+0x40的地址是16字節對齊的。
我們使用set $rsp=$rsp+1使得rsp加一
此時$rsp+0x40的值就不是16字節對齊了，我們使程序繼續運行.
可以看到程序crash掉了。
我從網上查了一下movaps這條指令。
movaps XMM,XMM/m128
movaps XMM/m128,XMM
把源存儲器內容值送入目的寄存器,當有m128時, 內存地址必須是16字節對齊的。
XMMWORD旨在表示與m128相同的類型,剛好這里符合第二條。
解決辦法
主要問題就是改變棧的地址。
-
改變payload的長度或填充一些其他的指令。
原本的payload，運行后棧如下 ret pop_rdi_ret bin_sh system 我們增加一些額外的指令，ret,ret 1,ret 2,ret 3等等 ret ret pop_rdi_ret bin_sh system -
如果有現成的后門可以用，改變返回地址的值在調用system函數，如下圖我們可以嘗試ret的地址為箭頭的地址。與1的思路差不多。
-
當payload有長度限制的時候，我們可以嘗試進行棧轉移來進行棧地址的改變，如果遇到了沒有對齊的情況就繼續將棧地址
+1，直到遇到棧對齊的情況。 -
調用execve