Shell's Home

Feb 19, 2016 - 1 minute read - Comments

一次升级故障的排查

问题描述

前两天,我收到了 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从业人员的青春,同时也产生更大的熵。