问题描述

前两天，我收到了 USN-2900-1 通知，glibc上有个严重漏洞，可导致DoS或（可能性的）执行任意代码。这个USN对应的CVE是CVE-2015-7547，我相信很多人应该听说过这个漏洞，或者应该已经修复了。我也不例外，很快的推进修复了这个漏洞。收到消息6-7小时后，已经看到了 POC 。

OK，我们本次不是讨论这个漏洞本身的。在漏洞修复后，有一台设备报错，无法安装程序，wget都无法执行。很有可能是漏洞修补补丁导致的。由于这个机器很关键，目前很难迁移，所以我需要找到原因。另一方面说，如果无法明确原因，已经执行补丁的机器群将无法确定可靠性。因此无论如何，必须要研究一下原因。

出问题的机器是一台ubuntu12.04，修补的版本号为2.15-0ubuntu10.13。

处理过程

首先，CVE的说明表明这个漏洞来自于getaddrinfo调用。因此首先确定问题和这个调用的关系。使用python，import socket，然后执行任意一个socket.getaddrinfo。python崩溃了。这就说明问题很可能来自本次修补。当然，同时的测试中表明wget也会崩溃，但是dig没事。所以dig很可能并没有产生getaddrinfo调用。

而后，我使用strace和tcpdump追踪了一下程序。tcpdump表明一切正常，并没有人正在攻击系统，因而可以排除修补不妥当加正在被攻击导致的崩溃。strace中断在ioctl调用后，除了进一步明确当时正在进行DNS查询外，并没有给出太多有效的信息。

常规来说，下一步应该是gdb。但是由于apt无法执行，所以gdb装不上去。因此我跳过gdb，先翻了一下USN-2900-1补丁的细节。这个补丁里包含了所有ubuntu自己打上去的补丁，因而有点大。但是仔细看之后可以分离出CVE-2015-7547补丁的位置：debian/patches/any/CVE-2015-7547.diff（还有pre1和pre2）。仔细阅读修补代码，尽管对逻辑并非十分清楚，但是并没有看到什么奇怪的错误。结合剩下的机器并没有问题，我基本认为这个补丁是没问题的。

后面很幸运的，向才发现虽然apt-get update不行，但是apt-get install却没问题。不知什么原因，总之我们有了一个能用的gdb系统。通过gdb，我确定了出问题的代码行号。我本来想省点事，从补丁上直接读出出问题的行（eglibc-2.15/resolv/res_send.c:1303）。但是很遗憾，出问题的行本身似乎没有什么问题。（*ansp2_malloced=1;）虽然可以看出是ansp2_malloced跑飞导致了SEGFAULT，但是并没有提示为什么。所以还是得需要完整的源码。

然后就是debian包维护的基本功夫。首先用apt-get source libc6下载源码。再用dpkg-source -x解开文件。进入目录里，用quilt push -a应用全部补丁（细节看 这里）。这样就得到了和线上一致的完整源码。我本来想将整个过程在目标机上完成，但是目标机上却无法安装quilt（根本找不到这个包，由于apt-get update无法执行，我也无法修正这个问题）。所以最后源码的补丁是在我本地的workstation完成的。

无论如何，我按照gdb的bt输出，仔细核对了出问题的代码。问题确实是出在了ansp2_malloced，这个值为0。但是这个值是逐层传递的参数，传递的最后几行表明这个值都是0，而在前面，这个值是有有效值的。可是吊诡的是，在有效变为无效的过程中，指针并没有修改过。

这个值是在__libc_res_nsearch(resolv/res_query.c:331)里发生变化的。在这个函数里，这个指针叫做answerp2_malloced。根据gdb的bt，在函数入口上，这个数值不为0。但是到了第421行，调用__libc_res_nquerydomain的时候，就变为了0。而从函数入口开始按照顺序搜索answerp2_malloced，都是对指针的值的修改，并没有对指针本身修改。函数也是传递指针，而不是双重指针。也就是说，answerp2_malloced在一个并不可能改变的代码段中被改变了。

读到这里的朋友，有兴趣的话可以先不要往下看，先猜猜原因。这个神秘的现象直到我看到结果，才反推出来为什么。

原因

我在这里被卡了很久。后来在无聊中，往下看了一下bt。留心到其中某个函数并没有调试信息，因为这个函数所在的so文件位置不对。仔细一看，这是一个glibc的库，但是却在/usr/local/lib下面。

我X。是哪个孙子把系统库的部分拷贝到了其他位置，还改变了LD路径。。。拿一个版本的glibc和另一个版本的glibc库混用，不出问题才见鬼咧。把这个so文件改名后，问题立刻解决。

复盘

事后根据复盘。这个参数其实是为了修补问题，新加的。原本__libc_res_nquerydomain函数并没有这个参数。然后为啥能跑？这涉及到linux下C的入栈顺序。这里不讲细节，如果你有兴趣，先看这个。再往下看复盘。

根据调用规则，调用者首先会对现场压栈。他会将需要保留的寄存器入栈，以防子程序改变他们。然后他会根据C规则或pascal规则入栈参数。最后call指令会将当前IP入栈，并且转跳到指定地址上。以这里的情况看，应该是默认的C规则。

C规则的好处在于被调用者获得的是栈顶相对位置，其余参数向栈底依次展开（注意下面用的全部是栈底/栈顶，由于对口，实际内存分布一般是反过来的）。使用BP+8，BP+12这种规则来访问。因此调用者可以传递变长参数。无论你在实际参数之前入栈了多少个数据，只要调用者最后记得把这些数据出栈，就不会对执行构成影响。而pascal规则则不然，为了获得参数位置，被调用者必须知道传入了多少个参数。例如访问第一个参数，就需要用BP+4*N+4来访问（当然在编译时这个数字会被静态的算出来）。如果你在实际参数之前入栈了数据，那么被调用者就需要用-1这种方法去访问这些数据了。而如果在实际参数之后入栈数据，整个参数位置都会错乱掉。因此pascal规则一般被认为是不能传递可变参数的。

但是C规则的这个优势，在这里变成了问题。调用者的代码还是打补丁之前的版本，而被调用者的代码则是打补丁之后的了。因此__libc_res_nsearch将参数入栈前入栈的最后一个元素认做了最后一个参数。这个元素，可能是需要保存的现场，也可能是局部变量。

如果__libc_res_nsearch将现场当作了最后一个元素的话，将无法解释这个值为什么在后面发生了变化——被保存的现场一般来说是用于未来的恢复的，他们不应当发生变化。而如果是局部变量则相反，局部变量的指针经常被当作参数传递给子函数——这也是经典的C多值返回方法。

如果__libc_res_nsearch确实接受了局部变量的地址作为参数，他可能会向这个地址写入任何东西——例如0。这就造成了这个地址在调用时有值，但是在使用时值被清零，又找不到任何地方修改这个值的缘故。

当然，这里也有很多疑惑。例如局部变量顶上一般会保存被调用者需要保存的现场。无论如何，参数和局部变量之间一点现场都不隔，是件很奇怪的事情。而现场一般是不变的。对于这点，我没时间去反向源码并分析栈的实际情况，谁知道可以告诉我。

这是一个调用者（caller）的原型认知比被调用者（callee）少一个参数的结果。如果事实反过来，调用者的原型认知比被调用者对一个参数，那么代码执行将不会有任何麻烦。

事后分析

这个故障最主要的原因是有人将系统库复制到了/usr/local，并修改了LD顺序。

glibc确实是一个几乎没有改动的库，但是这不表示他不会改动。根据我这里的记录，在过去的一年半时间里，他改变了八次。有趣的是，最早一次改动也是因为getaddrinfo的漏洞做修补（USN-2306-1）。也许是运气好，前几次改动中并没有调整参数，或者对参数的意义做变更。因此老代码和新代码的混合调用并没有出现问题。然而本次修补就过不去了。

这并不是ABI的错——ABI承诺的是“向外暴露接口”，而libc中的内部互相访问显然不在其中——谁会承诺自己内部结构的ABI兼容性呢？那会让稍微复杂点的重构都无法进行。

根本的问题在于，为什么有将glibc中的一部分提取出来，放在/usr/local中固化的需求呢？（或者对glibc的实现做调整）而且从操作上，即使我们需要对glibc动手脚，最好将整个编译结果放在/usr/local中，完整替换全部的glibc库。当然，这个行为会使得glibc的修补补丁彻底失效。根据运行时错误好过逻辑错误的理论，这是一件比崩溃更糟糕的事。

更糟糕的问题并不在glibc上，而是这台机器的维护状态，还好这是一台开发用机，而不是在线机器。如果有人知道这台机器的LD被做过手脚，应该很容易能够想到这个问题的原因。但是在复盘中我询问多个人，都不知道这台机器被如此设定的理由，甚至没人知道如何维护这台机器。实际上这台机器的维护曾多次易手，其中有些人根本已经离职。即使尚未离职，也未必记得自己到底做过哪些事。而我也找不到任何相关文档表明这台机器被如何的维护了。这也是为什么这台机器不好迁移的原因——在机器上有太多明的暗的诡异的workthrough，要将其迁移到另一台机器上是件耗费人工的事。我维护的很多机器（帮朋友维护）也处于类似的状态。维护时间太长，经手人多次转手，上面很多设定完全黑化，要迁移需要付出相当代价，等等。。。

docker能解决这个问题么？

不好说，这个问题有点复杂。

从本质上说，docker解决不了这个问题。因为一个workthrough，存在于整个系统中，还是存在于一片dockerfile的海洋中，其实没太大区别。如果我会跑上去就看dockerfile，然后从一大堆过程中一眼看出问题，那我也会在这次解决中先去看LD设定。最低限度，看bt的时候根本不用参考源码，往下看两行就知道原因了。而即便知道原因，这句cp存在于里面的原因仍然未知。我不知道为什么会把这个文件cp到/usr/local，无论是机器上实际存在的复制，还是dockerfile中的cp语句。最后实际有帮助的，还是在这句cp上注释的信息，或者机器上留存的维护文档。

但是docker是有帮助的。首先使用了docker起码好迁移了。当然，这不是他最大的帮助。

docker最大的帮助帮助并不是来自于能够帮助我简化寻找流程，或者知道原因。而是来自于减小系统规模，甚至可以将系统规模降低到需要的最小规模。在一个复杂系统中，寻找一个workthrough，或者知道为什么是困难的。但是在简洁系统就容易很多，非常多。

当然，将复杂系统拆分为简洁系统是有代价的，并不那么容易的。在这点上，我比较信奉熵增原则。在增大系统规模的时候，系统的熵永远是增加的。如果要降低熵，就需要对这个系统做功，无论从哪个方面。随着手段不同，做功只有大小差别，而没有一颗“一次解决”的银弹。从这个意义上说，docker并不能解决这个问题，他只是能降低你需要做的功。

而如果对某个系统做功并不产生实际效用（而只是为了将来可能性的维护便利）时，这部分开销就可能被砍掉。反正解决了问题并保持一段时间，相关人员可能就不再继续维护，或者高升，或者离职，或者根本转行。于是系统中（包括代码和维护）会不断产生各种workthrough，“将来要修”的承诺，和随着不断的人员变更不再有人记得的暗创。最后系统就会变成遗留系统，没人知道为什么，没人敢动，也不敢停。静静的在那里，吞噬一批又一批IT从业人员的青春，同时也产生更大的熵。