标签归档:DNS攻击

glibc再现漏洞 DNS成攻击Linux利器

上月,glibc(GNU C Library)再曝安全漏洞——编号为CVE-2015-7547的缓冲区溢出漏洞,该漏洞影响大多数Linux 服务器以及大量利用开源glibc搭建的网络架构和服务,如ssh, sudo, curl, PHP Rails 等。据谷歌安全团队分析,该漏洞位于glibc的DNS客户端解析器,应可绕过内存防护技术,从而形成代码执行漏洞。虽然这不是glibc第一次曝出安全漏洞,但由于DNS属于核心网络技术且很多互联网服务都依赖于它,再加上此漏洞出现在发行于2008年glibc2.9,应用于众多Linux发行版本中,所以此漏洞的影响范围非常广泛。
  实际上早在去年7月,glibc的维护人员就已经发现了这个问题,但当时这个编程上的问题被严重低估,后来谷歌的安全人员偶然发现了这个bug,在研究的过程中发现红帽的两位研究人员Florian Weimer 和 O’Donell也正在分析这个问题,但由于问题的严重性,两人并未公布相关信息,只是在私下进行研究。两个团队最终于2016年1月6日开始合作,共同修复这些源代码,合力开发了补丁更新。
  

漏洞影响

  glibc是GNU发布的libc库,它是Linux系统中最底层的API,几乎其它运行库都会依赖于glibc。glibc组件包含了大量标准库,这些标准库会被众多的程序调用。其中 libresolv库用来实现主机名与IP地址之间转换的功能。作为glibc包含的组件之一,nss_dns模块通过libresolv库进行DNS查询,从而实现Name Service Switch(NSS)服务。发现这个漏洞的谷歌研究人员解释,glibc通过alloca()函数在堆栈中保有2048字节。如果响应大于2048字节,就会从堆分配一个新的缓冲区,在某些情况下,会造成堆栈缓冲之间的不匹配,最后的结果就是,堆栈缓冲将被用于存储DNS响应,即使响应包大小超过了堆栈缓冲,该行为导致堆栈缓冲的溢出。Libresolv库中的代码在执行A/AAAA 双重DNS查询时会调用getaddrinfo库函数(处理域名到地址、服务到端口的转换)。远程攻击者可以通过创建特殊的DNS响应,如利用恶意域名服务器或中间人等,造成应用程序乃至系统崩溃,或进行远程代码执行,甚至取得root权限,调用函数send_dg(UDP查询)和send_vc(TCP查询)时会触发此缓冲区溢出。
  从对此漏洞的分析可以看出,承担众多互联网服务基础功能的DNS又一次成为了被攻击者利用的工具。尽管目前还没有证据表明已经有攻击者利用了此项漏洞,但为了系统安全考虑,在正式的补丁出来之前,不得不对glibc的DNS解析器做一些必要限制以减少漏洞利用的可能。如对于UDP查询,可采取的措施有:丢弃大于512字节的UDP DNS数据包、设置本地解析器以丢弃不一致的响应、避免A/AAAA双重查询,不使用EDNS0或DNSSEC等;对于TCP查询,限制所有DNS响应包大小在1024字节之内。但进行这些操作要慎之又慎,因为大型的DNS应答虽不常见,但不一定是恶意的,上述措施在规避漏洞利用的同时,可能会影响正常的DNS解析。庆幸的是,虽然Linux 操作系统还未更新,但glibc补丁已经发布,用户可以先打上glibc补丁阻断黑客的利用可能。
  

专家建议

  对于互联网上最广泛使用的DNS解析软件BIND是否会受到此漏洞的影响,BIND的开发和维护机构ISC(Internet Systems Consortium)认为,由于BIND的核心——指定域名服务器守护进程在进行DNS解析时,虽然使用的也是getaddrinfo()函数,但调用的是BIND本身的代码而不是系统库中的,所以此漏洞对基于BIND的DNS解析软件并无影响。但是一些实用程序或工具如dig、delv等,也隶属于BIND包,在进行DNS查询后会调用系统库中的 getaddrinfo()函数,所以尽管基于BIND的域名服务器风险很小,但ISC也强烈建议修复系统库。
  来自红帽的分析表明,编写成格式正确的、带有攻击者载荷的DNS响应将会穿透DNS缓存层次结构,允许攻击者利用这些缓存背后的机器。针对于此,DNS安全专家Dan Kaminsky也有着自己的见解:如果一个DNS漏洞可以渗透DNS的层次结构,那么问题已然升级,我们已经处在另一种危险之中,尤其是DNS应用如此广泛,一旦DNS查询导致了恶意代码执行,那结果显然是非常严重的。因此加固DNS缓存、加强架构部署,发展和支持网络基础设施建设,也是迫在眉睫的事。
  此漏洞也提醒我们,在DNS安全领域,攻击手段越来越多样化,攻击层面也更为深入。为此,国内领先的DNS解决方案提供商泰策也是非常担忧的。由于DNS对互联网业务的重要性,导致其成为许多网络攻击的目标,而DNS系统本身的脆弱性也大大提高了这些攻击的可能。此次涉及DNS的glibc漏洞,其发现用了八年,意味着给了攻击者八年时间来发现和利用这个漏洞。而现在,补丁虽然给出,但必须重启服务器,这对于一些业务来说也是破坏性的。所以这就需要互联网安全人员在问题出现之前,建设更为安全的网络平台。为此,泰策也呼吁业界要加强DNS安全建设,对于关键应用、关键部门所使用的DNS系统,采用更为可靠的商用解决方案,或者依赖专业技术服务团队的支撑,保证漏洞的及时修复和安全事件的及时响应。

glibc再现漏洞 DNS成攻击Linux利器

上月,glibc(GNU C Library)再曝安全漏洞——编号为CVE-2015-7547的缓冲区溢出漏洞,该漏洞影响大多数Linux 服务器以及大量利用开源glibc搭建的网络架构和服务,如ssh, sudo, curl, PHP Rails 等。据谷歌安全团队分析,该漏洞位于glibc的DNS客户端解析器,应可绕过内存防护技术,从而形成代码执行漏洞。虽然这不是glibc第一次曝出安全漏洞,但由于DNS属于核心网络技术且很多互联网服务都依赖于它,再加上此漏洞出现在发行于2008年glibc2.9,应用于众多Linux发行版本中,所以此漏洞的影响范围非常广泛。
  实际上早在去年7月,glibc的维护人员就已经发现了这个问题,但当时这个编程上的问题被严重低估,后来谷歌的安全人员偶然发现了这个bug,在研究的过程中发现红帽的两位研究人员Florian Weimer 和 O’Donell也正在分析这个问题,但由于问题的严重性,两人并未公布相关信息,只是在私下进行研究。两个团队最终于2016年1月6日开始合作,共同修复这些源代码,合力开发了补丁更新。

漏洞影响

glibc是GNU发布的libc库,它是Linux系统中最底层的API,几乎其它运行库都会依赖于glibc。glibc组件包含了大量标准库,这些标准库会被众多的程序调用。其中 libresolv库用来实现主机名与IP地址之间转换的功能。作为glibc包含的组件之一,nss_dns模块通过libresolv库进行DNS查询,从而实现Name Service Switch(NSS)服务。发现这个漏洞的谷歌研究人员解释,glibc通过alloca()函数在堆栈中保有2048字节。如果响应大于2048字节,就会从堆分配一个新的缓冲区,在某些情况下,会造成堆栈缓冲之间的不匹配,最后的结果就是,堆栈缓冲将被用于存储DNS响应,即使响应包大小超过了堆栈缓冲,该行为导致堆栈缓冲的溢出。Libresolv库中的代码在执行A/AAAA 双重DNS查询时会调用getaddrinfo库函数(处理域名到地址、服务到端口的转换)。远程攻击者可以通过创建特殊的DNS响应,如利用恶意域名服务器或中间人等,造成应用程序乃至系统崩溃,或进行远程代码执行,甚至取得root权限,调用函数send_dg(UDP查询)和send_vc(TCP查询)时会触发此缓冲区溢出。
  从对此漏洞的分析可以看出,承担众多互联网服务基础功能的DNS又一次成为了被攻击者利用的工具。尽管目前还没有证据表明已经有攻击者利用了此项漏洞,但为了系统安全考虑,在正式的补丁出来之前,不得不对glibc的DNS解析器做一些必要限制以减少漏洞利用的可能。如对于UDP查询,可采取的措施有:丢弃大于512字节的UDP DNS数据包、设置本地解析器以丢弃不一致的响应、避免A/AAAA双重查询,不使用EDNS0或DNSSEC等;对于TCP查询,限制所有DNS响应包大小在1024字节之内。但进行这些操作要慎之又慎,因为大型的DNS应答虽不常见,但不一定是恶意的,上述措施在规避漏洞利用的同时,可能会影响正常的DNS解析。庆幸的是,虽然Linux 操作系统还未更新,但glibc补丁已经发布,用户可以先打上glibc补丁阻断黑客的利用可能。

专家建议

对于互联网上最广泛使用的DNS解析软件BIND是否会受到此漏洞的影响,BIND的开发和维护机构ISC(Internet Systems Consortium)认为,由于BIND的核心——指定域名服务器守护进程在进行DNS解析时,虽然使用的也是getaddrinfo()函数,但调用的是BIND本身的代码而不是系统库中的,所以此漏洞对基于BIND的DNS解析软件并无影响。但是一些实用程序或工具如dig、delv等,也隶属于BIND包,在进行DNS查询后会调用系统库中的 getaddrinfo()函数,所以尽管基于BIND的域名服务器风险很小,但ISC也强烈建议修复系统库。
  来自红帽的分析表明,编写成格式正确的、带有攻击者载荷的DNS响应将会穿透DNS缓存层次结构,允许攻击者利用这些缓存背后的机器。针对于此,DNS安全专家Dan Kaminsky也有着自己的见解:如果一个DNS漏洞可以渗透DNS的层次结构,那么问题已然升级,我们已经处在另一种危险之中,尤其是DNS应用如此广泛,一旦DNS查询导致了恶意代码执行,那结果显然是非常严重的。因此加固DNS缓存、加强架构部署,发展和支持网络基础设施建设,也是迫在眉睫的事。
  此漏洞也提醒我们,在DNS安全领域,攻击手段越来越多样化,攻击层面也更为深入。为此,国内领先的DNS解决方案提供商泰策也是非常担忧的。由于DNS对互联网业务的重要性,导致其成为许多网络攻击的目标,而DNS系统本身的脆弱性也大大提高了这些攻击的可能。此次涉及DNS的glibc漏洞,其发现用了八年,意味着给了攻击者八年时间来发现和利用这个漏洞。而现在,补丁虽然给出,但必须重启服务器,这对于一些业务来说也是破坏性的。所以这就需要互联网安全人员在问题出现之前,建设更为安全的网络平台。为此,泰策也呼吁业界要加强DNS安全建设,对于关键应用、关键部门所使用的DNS系统,采用更为可靠的商用解决方案,或者依赖专业技术服务团队的支撑,保证漏洞的及时修复和安全事件的及时响应。