Heartbleed 是来自OpenSSL的紧急安全警告:OpenSSL出现“Heartbleed”安全漏洞。这一漏洞让任何人都能读取系统的运行内存,文名称叫做“心脏出血”、““击穿心脏””等。
为什么固定大小缓冲区这么流行
心脏出血漏洞是最新发现的安全问题,由长字符串导致缓冲区越界。最常见的缓冲区越界发生在如下两种条件同时满足中:
程序中一个组件A向另外一个组件B传递了一个指针,也可能同时传递长度信息
组件B忽略了,或者没有正确使用这个长度信息。此信息规定了指针所指向的内存区域能够存储多少数据。
上述条件都满足的程序结构之所以能引起缓冲区越界,一个重要原因是,调用者A分配了一块内存,但是只有当数据被真正读取的时候,才能知道程序到底需要分配多大的内存空间,因为不会被读取的数据,我们完全可以不保存它。 换句话说,一个函数负责分配空间,然后调用另外一个函数向该空间填充数据的结构,都会有点不安全。
即使这点危险能够通过正确的检查内存边界的方式成功避免,但是边界检查也会引入其自身存在的负面效果。 比如,我的一位前同事, 他创建了一个文本文件, 此文本文件压缩了数万个字符构成的单行字符串。 然后他又将这个文件作为输入,传递给了许多其他部件,比如编译器,文本处理程序等等。 几乎所有的这些程序都会出现这样那样的异常行为,例如,直接崩溃,或者悄无声息的忽略掉输入字符串的最后一截。
应对该问题的简单解决方案是:如果程序中任何部分涉及读入长度不确定的输入,那就应该负责分配足够大的内存来保存这些输入。当然,在C++语言中使用STL标准库就能轻松实现。但是在C语言中,却没有简单有效的实现代码,可以从输入读入一个单行字符串,返回包含该输入的内存指针,无视输入的长度。 任何在C语言中实现此功能的尝试,都或多或少的存在一些副作用。
我也曾静下心来在当时工作的部门,尝试在C语言库中增加一个针对上述问题的解决方案。 如果有人想要将使用了我写的函数的代码分享到别的地方,我想让他们也能将我写的函数作为其中一部分发布出去。 我所增加的函数的名称是readline,且为方便使用而设计:只需要传入一个文件指针(例如 stdin)作为输入,此函数就能读入一整行的输入,返回一个指向以NULL结尾的此字符串的第一个字符,无需考虑输入的长度。 如果读到了文件结束符(EOF),就返回一个NULL指针。
显然,任何分配内存,并返回指向该内存指针的函数都存在一个问题:该内存何时被释放? 我考虑过让readline函数的调用者负责释放,但是觉得很多调用函数可能会忘记释放内存。那么此时的缓冲区越界问题又变成了内存泄漏问题。
最后,我决定采取在别的地方看到的策略:readline将会返回一个指向内存空间的指针,并且保证其中的内容在下一次调用readline函数之前都会保持不变。这种策略不仅可以减少用户的担忧,而且也能让实现更简单:程序将存储一个静态指针(static pointer) 指向(动态分配的)缓冲区。缓冲区的大小将随读入的行的长度需要增减。 这种机制能让readline函数在最常用的场景中简单好用,并且安全。
代码如下 | |
char *line; while ((line = readline(stdin)) != NULL) { /* Process a line */ } |
当然,这种机制也有他自身存在的问题。比如,在同一个表达式中,两次调用readline函数将导致未定义行为(undefined behavior)。因为当程序员计划在第二次调用readline()函数之后,试图保存两次调用readline所读入的全部数据时,第一次调用所创建的内存空间,将在第二次调用时被释放掉。 此外,该代码会在读入输入的最后一行后,因为不再被调用,会一直占用内存空间。实际上,它所浪费的内存空间是整个输入中最长的那一行的长度。在实现该函数时,虽然我在缓冲区小于输入行长度时,都会重新分配更大的缓冲区,但是却没有允许缓冲区变小。因为我觉得反复分配释放内存的所导致的性能下降,相比于在少数清醒下浪费一点点内存空间来说不值得。
[Ok3w_NextPage]很显然,我高估了人们所能忍受的内存分配延迟开销:当我几个月后回头看这些代码时,发现有人已经将我所写的readline版本完全修改为固定的4096-字符缓冲区。据我所了解,他的动机是完全避免运行时存储分配的开销。换句话说,为了避免只有在少数情况下才存在的多次内存分配器调用,他悄悄的让所有使用readline函数的程序,在行的长度大于4096个字符时,出现了很大的安全隐患。
之所以花了大量的篇幅讲这样一个故事,是因为它透露出我觉得非常重要的几点:
缓冲区越界通常发生在程序中某个部分A分配内存,而实际需要的存储空间大小只有另一个部分B知道。
在程序中的同一个函数内部分配内存,并将其填充。这种方式解决了缓冲区分配的问题,而付出的代价是必须要让程序的另一个函数负责内存的释放。内存的分配和释放在程序的两个不同的函数中。
这种分配和释放在两个不同的函数将会导致程序的可用性问题,除非在编程语言上有系统的支持,否则很难绕开。
即使用户为了安全和通用性,需要接收这个现实,但是他们可能也无法接受动态分配内存引入的开销。
我想,程序员不愿为了安全而引入运行时开销,是很多安全性问题之所以普遍存在的原因。 我们将在下周详细聊聊这种现象。