gcc是否在编译时重新排序局部变量?

时间:2016-08-11 08:29:54

标签: c gcc gdb reverse-engineering buffer-overflow

我目前正在阅读(第二次)“黑客攻击:剥削艺术”并且偶然发现了什么。

本书提出了两种不同的方法来利用这两个类似的程序:auth_overflowauth_overflow2

在第一个中,有一个像这样的

的密码检查功能
int check_authentication(char *password) {
    int auth_flag = 0;
    char password_buffer[16];

    strcpy(password_buffer, password);
    ...
}

输入超过16个ASCII字符会将auth_flag的值更改为大于0的值,从而绕过检查,如此gdb输出所示:

gdb$ x/12x $esp
0xbffff400: 0xffffffff  0x0000002f  0xb7e0fd24  0x41414141
0xbffff410: 0x41414141  0x41414141  0x41414141  0x00000001
0xbffff420: 0x00000002  0xbffff4f4  0xbffff448  0x08048556

password_buffer @ 0xbffff40c
auth_flag @ 0xbffff41c

第二个程序反转了两个变量:

int check_authentication(char *password) {
    char password_buffer[16];
    int auth_flag = 0;

    strcpy(password_buffer, password);
    ...
}

然后作者建议,不可能溢出到auth_flag,我真的相信。然后我继续溢出缓冲区,令我惊讶的是,它仍然有效。 auth_flag变量仍然位于缓冲区之后,正如您在此gdb输出中看到的那样:

gdb$ x/12x $esp
0xbffff400: 0xffffffff  0x0000002f  0xb7e0fd24  0x41414141
0xbffff410: 0x41414141  0x41414141  0x41414141  0x00000001
0xbffff420: 0x00000002  0xbffff4f4  0xbffff448  0x08048556

password_buffer @ 0xbffff40c
auth_flag @ 0xbffff41c

我想知道gcc是否没有重新排序局部变量用于对齐/优化目的。

我尝试使用-O0标志进行编译,但结果是一样的。

你们其中一个人知道为什么会这样吗?

提前致谢。

3 个答案:

答案 0 :(得分:11)

编译器作者可以完全自由地为具有自动存储的局部变量实现任何分配方案。 auth_flag可以在堆栈上password_buffer之前或之后设置,它可以在寄存器中,如果对代码进行适当的分析,它可以完全省略。甚至可能没有堆栈......标准给你的唯一保证就是:

如果包含空终止符的源字符串比目标数组strcpy(password_buffer, password);长,则

password_buffer将调用未定义的行为。 未定义的行为是否符合您的需求完全超出了语言规范。

事实上,一些实现者通过在发布的代码等情况下随机化行为,故意使黑客的任务变得复杂。

答案 1 :(得分:0)

我有同样的问题。为了解决此问题,请将两个变量放入结构中。在结构中,字段始终按结构中的定义进行定位。请注意,顺序相反。

struct myStruct {
       int auth_flag;
       char password_buffer[16];
};

答案 2 :(得分:0)

我知道这是一个老问题。

但就我而言,-fno-stack-protector 标志起到了作用。 因此,如果我使用 -fno-stack-protector 进行编译,则局部变量按例外排序(至少对于这个简单程序而言)。

我想知道,也许重新排序可以起到某种保护作用。 Here I found link about that