立即修复！Unix bug令各类Linux系统身陷风险
此安全漏洞（CVE 2015-7547）为存在于glibc DNS客户端解析器之getaddrinfo()函数中的基于堆栈缓冲区溢出问题，且目前已经得到修复。任何使用glibc 2.9以及更新版本（2.9版本于2008年5月发布）的用户都有可能受到影响，这意味着几乎全部glibc使用者都应当尽快安装该补丁。红帽企业Linux 5采用glibc 2.5，因此其不会受到该漏洞的影响; 不过红帽企业Linux 6（使用glibc 2.12）、红帽企业Linux 7（使用glibc 2.17）、Debian squeeze（使用glibc 2.11）、Debian wheezy（使用glibc 2.13）以及Debian jessie（使用glibc 2.19）则全部受到影响。
“必须认真对待这一问题，即尽快为glibc安装修复补丁。该安全漏洞确实非常严重，”Open Crypto Audit项目主管兼安全研究员Kenneth White在自己的推文当中写道。
该漏洞最初由Ciena的Robert Holiday及其glibc项目小组所报告，时间点为2015年7月。在此之后，红帽公司首席软件工程师Carlos O’Donnell与红帽产品安全团队成员Florian Weiner对该漏洞的影响做出评估并为其准备了相应补丁。谷歌公司研究员Fermin J. Serna与Kevin Stadmeyer亦独立发现了报告中提及的该安全漏洞，并推出了一项针对该漏洞的概念验证利用方案。
“我们还没有发现任何使用这项安全漏洞的实际攻击活动，”O’Donnell指出。
其中getaddrinfo()函数通常被用于解析IP地址，在这种情况下，攻击者可以利用该漏洞通过接入恶意DNS服务器实现对应用程序及系统的控制权。利用这一安全漏洞进行攻击的可行途径多种多样，其中包括但不限于ssh、sudo以及curl，谷歌研究人员们解释称。
“使用该函数的软件可能被攻击者通过受控域名、攻击者控制之DNS服务器或者中间人攻击活动所影响，”Serna与Stadmeyer在咨询意见当中写道。
该安全漏洞会在系统从DNS服务器处接收到长度过大的UDP或者TCP响应结果时被触发，具体为超过2048字节——而在此之前，攻击者还需通过另一项响应对该堆栈进行覆盖。要触发这项缓冲区管理漏洞，目标系统必须尝试对攻击者控制下的域名进行DNS搜索。第一条接收到的响应长度为2048字节，这意味着其会占满整个缓冲区、不留任何剩余空间。由于该缓冲区无法进行复用，因此系统会建立一个新的缓冲区。但漏洞的存在导致原有缓冲区与新缓冲区同时存在，意味着整体缓冲区空间为65535.第二项响应则迫使该系统重试这项查询。第三项响应包含有2048字节的有效响应，但除此之外攻击载荷仍有63487字节空间可以使用。
该漏洞之所以会发生，是因为当该查询重新开始时，其指向的其实是拥有错误容量的缓冲区，O’Donnell解释道。“当然还有其它办法触发这个缓冲区管理漏洞，但其需要对响应计时进行深入控制，并使用轮询超时以通过两次攻击者响应实现漏洞利用（而非三次），”O’Donnell表示。
红帽公司的研究员们还得以利用该缓冲区溢出漏洞控制一项free()调用的执行，并借此控制EIP注册表。尽管他们并没有尝试进一步利用该漏洞，但此次尝试已经证明了远程控制执行的可能性。
“包络分析结果显示，攻击者可以利用受控载荷编写出格式正确的DNS响应，从而突破DNS缓存结构并借此接入到缓存背后的设备本体，”O’Donnell在其glibc项目群发邮件中写道。
该漏洞产生的危害水平取决于系统现有缓冲区溢出漏洞应对能力。远程代码执行可能“并不简单”，因为其需要绕过ASLR，谷歌公司的Serna解释称。管理员与开发人员如果无法立即安装glibc补丁，也应当马上采取临时性应对措施，从而防止潜在的攻击行为。一种可行选项在于将本地DNS解析器所能接收的响应长度限制在1024字节。
对于这种长度限制需要高度关注，因为使用DNSSEC等先进功能的系统可能需要接受超出正常长度水平的UDP响应。DNSSEC需要配合EDNSO，这项客户端功能负责通知服务器其能够接收长度超过512字节的UDP响应。因此，阻断高长度DNS响应有可能会破坏EDNSO功能。“DNS解析可能因此发生失败，或者出现显著延迟，”SAN协会的Johannes B. Ullrich提醒称。
管理员应当确保网络之上的全部系统都采用特定解析器，同时阻断一切出站DNS——除非其由已知解析器所生成。通过这种方式能够限制漏洞被利用的可能性，而且“是种不错的处理办法，”Ullrich指出。
与此同时，禁止双A与AAA查询可能也有助于缓解这种安全漏洞，而彻底禁用IPv6则无法禁用AAAA查询或者预防漏洞问题。阻断IPv6的本地或者中间解析器并不能预防此类漏洞状况，因为漏洞利用载荷仍然能够得到切实交付。“它属于触发该缓冲区管理漏洞的并发查询，”O’Donnell写道。
尽管相关补丁已经正式推出，不过这场竞赛仍在进行当中，而且最终结果取决于哪方行动更快——攻击者还是防御者。“现在捕鼠猫已经出笼，开发团队需要快速检测其应用程序是否处于风险当中：但这项工作非常困难，因为glibc以深层方式集成在各类应用当中，”Black Duck软件公司的Patrick Carey表示。修复的过程同样相当漫长，特别对于那些移动设备或者其它面向用户的应用程序而言。