【安全预警】关于runc容器逃逸漏洞通知

腾讯云安全中心发现runc存在容器逃逸漏洞,允许恶意容器覆盖Host上的runc文件,以root权限执行代码,威胁容器及主机安全。CVSSv3评分为7.2,属高风险。

尊敬的腾讯云客户,您好: 

   近日,腾讯云安全中心监测发现轻量级容器运行环境runc被爆存在容器逃逸漏洞,攻击者可以在利用该漏洞覆盖Host上的runc文件,从而在Host上以root权限执行代码。

        为避免您的业务受影响,腾讯云安全中心建议您及时开展安全自查,如在受影响范围,请您及时进行更新修复,避免被外部攻击者入侵。

 

【漏洞详情】

         runc是一个轻量级通用容器运行环境,它是一个命令行工具,可以根据开放容器方案(Open Container Initiative)生成和运行容器,该漏洞若被利用,会允许恶意容器(以最少的用户交互)覆盖Host上的runc文件,从而在Host上以root权限执行代码,进而攻击其它容器或Host。目前CVSSv3官方评分达7.2分。

 

【风险等级】

   高风险

 

【漏洞风险】

   容器逃逸攻击风险,存在漏洞的runc被利用后可以获取Host的root权限,并利用该权限攻击其他容器或机器。

 

【影响版本】

       除runc之外,Apache Mesos、LXC也在受影响之列。

 

【修复建议】

        若您使用的是腾讯云容器服务TKE, 您可以通过以下方法进行漏洞修复

        1. TKE 已经修复增量版本,新创建的集群和新加入的节点不受影响


        2.若Docker版本为17.12.1的容器节点,可用root权限执行以下命令升级runc版本。此方法不影响该节点正在运行的业务。


        wget  http://static.ccs.tencentyun.com/docker17.12-runc-e25b2183f 

        chmod +x ./docker17.12-runc-e25b2183f
        mv /usr/bin/docker-runc /usr/bin/docker-runc-$(date -Iseconds)
        mv docker17.12-runc-e25b2183f /usr/bin/docker-runc 


         验证是否升级成功:
         执行docker-runc -v, 应该看到如下版本信息:


         runc version 1.0.0-rc4+dev
         commit: e25b2183f48e942cb41582898acbf7e24b5d2f31
         spec: 1.0.0


         3. 目前TKE已修复增量Docker版本,您存量的节点可以通过移出集群再加入集群触发节点重新初始化进行修复。此方法不限制Docker版本但会造成节点重启。

 

【漏洞参考】

  1)漏洞详情:https://www.openwall.com/lists/oss-security/2019/02/11/2

  2)修复参考:https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b 

  3)LXC修复:https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d

转载于:https://my.oschina.net/u/3799788/blog/3010177

9 月 19 日,腾讯云安全中心监测到  Apache Tomcat 修复了2个严重级别的漏洞, 分别为: 信息泄露漏洞(CVE-2017-12616)、远程代码执行漏洞(CVE-2017-12615),在某些场景下,攻击者将分别能通过这两个漏洞,获取用户服务器上 JSP 文件的源代码,或是通过精心构造的攻击请求,向用户服务器上传恶意 JSP 文件,通过上传的 JSP 文件 ,可在用户服务器上执行任意代码。      云鼎实验室通过对于漏洞描述,搭建漏洞环境,并对其进行复现。此漏洞为高危漏洞,即使是非默认配置,但是一旦存在漏洞,那么攻击者可以成功上传 webshell,并控制服务器。 复现 根据描述,在 Windows 服务器下,将 readonly 参数设置为 false 时,即可通过 PUT 方式创建一个 JSP 文件,并可以执行任意代码。    通过阅读 conf/web.xml 文件,可以发现:   默认 readonly 为 true,当 readonly 设置为 false 时,可以通过 PUT / DELETE 进行文件操控。   配置 readonly 为 false: 启动 Tomcat,利用 PUT 请求创建文件: 提示 404。通过描述中的 Windows 受影响,可以结合 Windows 的特性。其一是 NTFS 文件流,其二是文件名的相关限制(如 Windows 中文件名不能以空格结尾)来绕过限制:  访问发现可以正常输出:  分析 Tomcat 的 Servlet 是在 conf/web.xml 配置的,通过配置文件可知,当后缀名为 .jsp 和 .jspx 的时候,是通过JspServlet处理请求的:   可以得知,“1.jsp ”(末尾有一个和空格)并不能匹配到 JspServlet,而是会交由DefaultServlet去处理。当处理 PUT 请求时: 会调用resources.rebind: dirContext 为FileDirContext: 调用 rebind创建文件: 又由于 Windows 不允许“ ”作为文件名结尾,所以会创建一个 .jsp 文件,导致代码执行。 Bypass 分析 然而,经过黑盒测试,当 PUT 地址为/1.jsp/时,仍然会创建 JSP,会影响 Linux 和 Windows 服务器,并且 Bypass 了之前的补丁,分析如下。  在进入 bind 函数时,会声明一个 File 变量: 进入 File 后,会对 name 进行 normalize 最后得到的 path 就是没有最后 / 的 path 了: 影响  由于存在去掉最后的 / 的特性,那么这个漏洞自然影响 Linux 以及 Windows 版本。而且经过测试,这个漏洞影响全部的 Tomcat 版本,从 5.x 到 9.x 无不中枪。目前来说,最好的解决方式是将 conf/web.xml 中对于 DefaultServlet 的 readonly 设置为 true,才能防止漏洞
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值